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1.0  INTRODUCTION 

1.1  PURPOSE 

The  purpose  of  this  document  is  to  defiitt  the  ARWA  Simulator  Verification  and 
Validation  ^&V)  Plan.  This  V&V  plan  describes  the  activities  required  to  verify  and 
vaUdate  the  ARWA  SS. 

1.2  Overview 

The  following  provides  a  brief  description  of  the  major  sections  of  this  document: 

Section  2  provides  a  summary  description  of  the  ARWA  SS.  Also  described  is 
the  approach  taken  to  selectively  conduct  V&V  activities.  This 
approach  is  necessary  in  order  to  use  the  V&V  resources  most 
effectively.  V&V  intensity  levels  and  the  speciHc  activities  to  be 
performed  are  also  defined  in  this  section.  The  Configuration 
Management  approach  is  discussed  and  the  participating  agencies  are 
identified. 

Section  3  defines  the  V&V  respon^bilities. 

Section  4  defines  the  purpose  and  objectives  of  the  ARWA  SS.  The  model 
hierarchy  is  described  and  the  intended  uses  of  the  ARWA  SS  are 
defined. 

Section  5  identifies  the  information  sources  used  in  the  development  of  this 
V&V  plan. 

Section  6  defines  the  verification  activities  and  products  for  each  of  the  ARWA 
components. 

Section  7  defines  the  validation  activities  and  products  for  each  of  the  ARWA 
components. 

Section  8  defines  the  accreditation  plan  for  each  of  the  ARWA  components. 
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2.0  BACKGROUND 


2.1  DESCRIPTION 

The  ARWA  SS  provides  the  capability  to  engage  in  simulated  war  Hghting 
exercises  within  the  Battlefield  Distributed  Simulation  Development  (BDS-D)  environment 
for  the  purpose  of  rapidly  exploring  tactics,  doctrine  and  combat  system  development 
issues.  The  ARWA  SS  is  a  real-time,  software  intensive,  network  interoperable  simulation 
capable  of  supporting  reconfiguration  to  any  combination  of  two  RAH-66  or  two  AH-64D. 
The  software  simulation  is  data  driven  to  provide  easy  access  to  critical  parameters  for 
modification  purposes  in  an  experimentation  environment  The  ARWA  SS  consists  of  two 
(2)  devices  which  can  be  individually  reconfigured  in  various  combinations  of  the  aircraft 
listed  above. 

2.2  V&V  Approach 

The  overall  approach  to  V&V  of  the  ARWA  SS  is  shown  in  Figure  2.2-1.  The 
METL  is  the  Mission  Essential  Task  List  This  document  defines  the  ba.sic  missions  which 
the  simulated  aircraft  must  perform.  The  Task  and  Skills  Analysis  (TSA)  uses  the  METL 
to  derive  the  crew  tasks  which  the  pilot  and  co-pilot/gunner  must  perform  in  the 
accomplishment  of  the  missions.  The  Selected  Hdelity  Analysis  (SFA)  uses  the  TSA  and 
the  defined  purpose  and  expectations  of  the  ARWA  SS  to  define  the  specific  functions  that 
must  be  included  in  the  ARWA  SS  and  to  what  level  of  fidelity  they  must  be  represented. 
The  SFA  ou^ut  is  used  by  the  development  team  together  with  the  government  furnished 
requirements  and  the  ARWA  SS  statement  of  work  (SOW)  to  define  the  tequiienienis  and 
specifications  for  the  developers  of  the  ARWA  SS  capabilities,  namely  Loral,  Pulau, 
Boeing,  and  McDonnell  Douglas  Helicopter  Company  (NO^HQ. 

The  targets  for  V&V  activities  are 

•  the  aforementioned  ARWA  simulation  requirements 

•  the  integrated  ARWA  SS 

•  the  components  of  the  ARWA  SS  such  as  the  Visual  System  Module 
(VSM),  the  Flight  Station  Module  (FSM),  and  tlie  Simulator  System 
Module  (SSM) 

•  the  computer  software  configuration  items  (CSCI)  which  comprise  the 
above  components 

•  the  computer  software  components  (CSC)  which  comprise  the  CSCls 

•  the  computer  software  units  (CSU)  which  comprise  the  CSCs 

The  large  number  of  V&V  targets  and  the  limited  resources  which  are  available  for 
the  V&V  effort  make  it  impractical  to  perform  a  complete  set  of  V&V  activities  to  all 
components  of  the  ARWA  SS.  The  concept  of  performing  a  subset  of  V&V  activities  to 
selected  components  was  developed  to  ensure  that  all  components  of  the  ARWA  SS  have 
been  considered  from  the  V&V  perspective.  This  concept  is  implemented  by  identifying 
V&V  'intensity  levels.'  A  summary  of  these  levels  is  shown  in  Figure  2.2-1.  An 
expansion  of  ttese  level  definitions  is  given  below. 
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REQUIREMENTS 


V&VINTENSITYLEVELS: 

1  ComplatoSatOfVEV 
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2  Subeet  of  Level  IV&VActivHie* 

3  Minimum  Verification. 
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Aggregate  Level* 
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and  Expectations 
of  the  Simulation 


ARWA  SIM  DEVELOPER 
REQUIREMENTS 
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VEfVRCATION 

MATRIX 


JNCnONS 


lcsc> 


V  A  V  INTENSITY  LEVELS 
SELECTED  FOR  TARGETS 
BASED  UPON: 

•  Intended  Reuse 

-  Code /Model  Maturity 
>  Previous  VAV  Effort* 

•  Applicability  To  Other 
Simulators 

•  Development  Schedule 


VAVTARGET 


ICSU 


Figure  2.2-1  ARWA  SS  V&V  Approach. 

V&V  Level  1 

Full  set  of  verification  and  validation  activities  must  be  perfonned.  The  following 
tasks  must  be  completed: 

•  logic  verification 
«  c(^  verification 

•  structure  validation 

•  output  validation 


V&V  Level  2 

A  subset  of  the  Level  1  activities  must  be  performed.  Automated  analysis  may 
necessary  to  cover  all  required  cases.  Verification  and  or  validation  activities  may 
omitted,  depending  on  previous  V&V  efforts,  potential  reuse,  available  resources,  or 
schedule  constraints. 


Y.&YUY613 

Basic  verification  is  required.  Inspection  of  output  and  manual  comparison  to 
predicted  results  may  be  sufficient.  Validation  may  be  accomplished  in  conjunction  with 
the  validation  of  other  components. 
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The  selectimi  of  the  V&V  intensity  kvd  to  apply  to  each  ARWA  SS  component  is 
based  on  die  following  criteria: 

•  selected  fidelity  of  the  segment 

•  importance  of  segment  to  overall  &ielity 

•  code  maturity  and  complexity 

•  reuse  potential 

•  devel^ment  schedule 

•  V&V  resources 

The  process  of  assigning  intensity  levels  to  the  ARWA  SS  segments  is  shown  in 
Figure  2.2-2.  This  process,  called  criticality  analysis  in  the  figure,  identifies  the  V&V 
intensity  level  assigned  to  segments.  The  inputs  to  the  criticality  analysis  are  the  selected 
fidelity  from  the  TSA/SFA  and  the  applications  for  which  the  ARWA  is  intended.  The 
outputs  are  the  V&V  intensity  level  assignments  and  the  required  ARWA  SS  functionality. 


Figure  2. 2. -2  v&v  intensity  level  Assignment. 


-4- 


ADST/TR  94-003282 


April  IS,  1994 


2.3  SUMMARY  OF  V&V  INTENSITY  LEVEL  ASSIGNMENTS 

The  following  V&V  Intensity  Level  Assignments  were  made  prior  to  the  first 
Steering  Ccmimittee  meeting  held  October  26, 1993. 

VISUAL  SYSTEM  MODULE  (VSM) 

Level:  3 

Reuse:  GFE  hardware,  COTS  software.  Generic,  reusable  software;  interface 
module  is  hardware  dependent.  Data  bases  GFE;  converted/generated 
from  reusable  genetic  format  Generic  modules  reused. 

Code  maturity:  Much  of  Phase  I  is  legacy  code  that  has  been  used  on 

previous  programs.  Phase  II  provides  new  code.  CIG 
has  completed  acceptance  test  procedures. 

Code  complexity:  High  algorithmical,  high  computational,  and  high 

interface. 

FLIGHT  STATION  MODULE  (FSM)  BASE  Gncludes  Internal  Bus  Interface  Unit) 
Level:  2 

Reuse:  Interface  software  built  of  generic  layers  used  by  each  module/segment 
with  specific  application  layers  for  a  specific  module/segment 
Code  maturity:  Mature  code  that  will  be  modified. 

Code  complexity:  Moderate  algorithmical.  High  number  of  interfaces. 

High  computational. 

SIMULATOR  SYSTEM  MODULE  (SSM)  -  BASE 
Level:  1 

Reuse:  Has  high  reuse  potential  for  other  aircraft  in  similar  DIS  applications. 
Code  maturity:  Combination  of  reused  and  modified  code. 

Code  complexity:  High  algorithmical  and  computational.  Moderate 

interface. 

SIMULATOR  SYSTEM  MODULE-RAH-66 
Level:  2 

Reuse:  Reuse  for  other  aircraft  with  similar  or  same  systems.  Interface 
documentation  facilitates  reusability. 

Code  maturity:  Modified  code  that  must  be  verified  and  validated  in  the 

ARWA  SS  environment. 

Code  complexity:  Moderate  algorithmical.  High  number  of  interfaces. 

High  computational. 

RAH-66  FUGHT  STATION  MODULE 
Level:  2 

Reuse:  Reuse  for  other  aircraft  with  similar  or  same  systems.  Reusable, 
common  COTS  graphics  engine  reconfigured  through  selection  of 
generic  library  routines;  common  sound  generation  module  using  data 
files.  Reconfigurable  base,  controls,  and  displays.  Data  files  for 
specific  A/C  subsystems,  generic  at  high  level.  Interface 
documentation  facilitates  reusability. 

Code  maturity:  Modified  code  that  must  be  verified  and  validated  in  the 

ARWA  SS  environment 

Code  complexity:  Moderate  algorithmical.  High  number  of  interfaces. 

High  computational. 
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SIMULATOR  SYSTEM  MODULE-AH-64D 
Level:  2 

Reuse:  Reuse  for  other  aircraft  with  similar  or  same  systems.  Interface 
documentation  facilitates  reusability. 

Code  maturity:  Modified  code  that  must  be  verified  and  validated  in  the 

ARWA  SS  environment 

Code  complexity:  Moderate  algorithmical.  High  number  of  interfaces. 

High  computational. 

AH-64D  FUGHT  STATION  MODULE 
Level:  2 

Reuse:  Reuse  for  other  aircraft  with  similar  or  same  systems.  Reusable, 

common  COTS  graphics  engine  reconfigured  through  selection  of 
generic  library  routines;  common  sound  generation  module  using  data 
nies.  Reconflgurable  base,  controls,  and  displays.  Data  files  for 
specific  A/C  subsystems,  generic  at  high  level.  Interface 
documentation  facilitates  reusability. 

Code  maturity:  Modified  code  that  must  be  verified  and  validated  in  the 

ARWA  SS  environment 

Code  complexity:  Moderate  algorithmical.  High  number  of  interfaces. 

High  computational. 

The  following  are  support  software  products  from  the  DIS  BDS-D  delivery  order: 

SESSION  MANAGER  S/S 
OPERATIONAL  AND  LOGISTICS  SUPPORT  S/S 
MISSION  PLANNING  S/S 
AFTER  ACTION  REVIEW  S/S 
ARWA  LAN  S/S 
DIS  NETWORK  MANAGER  S/S 
ENVIRONMENTAL  SIMULATOR  S/S 
Level:  3 

Reuse:  High  level  of  reuse  for  oUier  simulators. 

Code  matuhty:  Mostly  reused  code;  some  modification  for  specific  kits/ 

mi.s.sions. 

Code  complexity:  Moderate  algorithmical.  High  number  of  interfaces. 

High  computational. 

A  summary  of  the  intensity  level  assignments  to  each  module  and  submodule  is 
shown  in  Table  2.3-1.  This  table  also  contains  the  number  of  source  lines  of  code 
estimated  for  each  module  and  the  estimated  number  of  labor  hours  required  to  accomplish 
the  V&V  activities  for  the  assigned  intensity  level. 
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TABLE  23-1  INTENSITY  LEVEL  ASSIGNMENTS 


Sagimnt 


VAV  lv«riflcation 
InlMitily' 


Valklalion 


Struetura  I  Output 


Ibttil 

SLOG  Liter 
Hour* 


Vbual  Systpm  Moduto  (VSM) 
Ovwmll 

Integration  VliV 

VSM_NelworK_lnterface 

VSM.UaorJnterface 

VSM_HardwMiraJntBrfac« 

VSM_Raaoureo_Managar 

ProcMa.Schaduler 

OTW_Oiaplay« 

HeadJTracker 

H«lmet_iyiounted_Display 

Admin.Conaola 

ComputerJmage.Gonerator 


Flight  Station  Moduie  (FSM) 
Ovwmil 

Integration  V&V 
FSMBaae 
FSM  Conuinehe 
FSM  Longbow 


Simulation  System  Module 
(SSM  Base) 

OntmU 

Integration  V&V 

Control 

TNE 

Bus  Interface  Unit 


CockpRKn 
RAH-66  Comanche  Kit 
Onmtt 

RAH46  Flight  Controls 
RAHS6  Nav/Comm 
RAH«6  Weapons 
RAH46  Sensors 
RAH^ASE 
RAH46  Flight  Dynamics 
RAH^  Propuision 
RAH^  Physical  Cues 
RAIf66  TNE  (see  SSM  Base) 


ADST/TR  94-003282 


April  15,  1994 


TABLE  2.3*1 .  INTENSTTY  LEVEL  ASSIGNMENTS  CONTINUED 


V&V 

Segment 

InteneKy 

Level 

NOTES 

X  Specific  V&V  activity  required. 

1  Assumes  Level  1  V&V  intensity. 

-  Assumed  LOG  per  hour  to  perform  Verification.  30 

-  Assumed  LOG  per  hour  to  perform  Validation.  30 

2  2  labor  months  for  overall  VSM  V&V. 

3  Only  functional  verification  is  required. 

4  Verified  and  validated  by  passing  VSM  acceptance  test. 

5  Assumes  higher  rate  LOG  per  hour.  240 

6  Assumed  higher  rate  LOG  per  hour.  240 

7  2  labor  months  for  overall  FSM  V&V. 

8  Validated  by  passing  FSM  acceptance  test. 

9  2  labor  months  for  overall  SSM  Base  V&V. 

1 0  Support  Software  had  previously  been  rated  Level  3. 

1 1  Verified  and  validated  by  passing  DIS  device  acceptance  test. 

12  ModSAF  will  be  V&V'd  under  a  separate,  leveraged  DO. 
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2.4  Schedule 

A  top  level  summary  schedule  of  V&V  activities  is  shown  in  Figure  2.4-1.  The 
basic  timeline  associated  with  the  output  validation  process  of  individual  segments  is 
shown  in  this  figure.  The  timeline  associated  with  the  integration  of  all  simulator  segments 
will  require  the  iteration  of  output  validation  of  each  segment  as  the  integration  progresses. 
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Figure  2.4-1  SCHEDULE  OF  V&V ACTIVITIES 
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2.5  Configuration  Management 

This  section  (2.5)  was  extracted  from  a  document  provided  by  Loral.  This 
document  is  being  updated  and  modified  to  meet  the  ARWA  SS  requirements.  This  excerpt 
was  included  to  provide  a  general  description  of  the  CM  plan  that  Loral  proposes  to  adopt 
for  the  ARWA  SS  program. 

Loral  has  established  the  Configuration  Management  (CM)  practices  and  procedures 
to  be  followed  in  support  of  the  Advanced  Distributed  Simulation  Technology  (ADST) 
contract  by  Loral  Advanced  Distributed  Simulation  (LADS).  The  plan  describe  the  CM 
practices  and  procedures  required  for  the  concurrent,  multi-site  development  and  support  of 
the  ADST  BDS-D  (Battlefield  Distributed  Simulation-Development)  programs.  This  plan 
addresses  the  Software  Development  Facility  in  Orlando,  and  subcontractors  working  on 
ADST  Delivery  Orders  (DO's).  Ft  Knox  and  Ft  Rucker. 

A  contractor  managed.  Configuration  Control  Board  (CCB)  will  be  established  at 
the  Loral  ADST.  Orlando  facility,  which  will  monitor,  approve,  and  control  changes  to  the 
common  ADST  product  baseline.  The  centraliied  CCB  will  be  responsible  for  adjudicating 
baseline  changes  proposed  by  the  various  development,  operational,  and  integration 
functions.  This  plan  describes  the  configuration  change  control  procedures  to  be  followed 
by  the  CCB  and  identifies  the  relationship  of  development  and  integration  sites  (i.e., 
Orlando,  Ft.  Knox,  Boeing  -  Huntsville,  MDHC  -  Mesa,  and  Ft.  Rucker)  and 
subcontractors  working  on  ADST  Delivery  Orders 
(DOS). 


Each  Delivery  Order  (DO)  organkatioii  will  apply  standard  practices  and  processes 
to  its  design/development  and  integration  activity.  Systems  Engineering  will  be  re^nsible 
for  the  initiation,  development,  and  coordination  of  all  DO’s  on  the  ADST  program.  CM 
will  work  closely  with  software  and  systems  engineering  to  assure  consistency,  and 
integrity  of  the  initial  submissions,  procedural  changes  and  traceability  of  software  and 
hardware  components.  Systems  Engineering,  along  with  the  Program  Engineering 
Manager  will  be  a  liaison  with  the  CCB  and  will  coordinate  with  software  engineering, 
integration  and  CM  on  software  deliveries.  In  order  to  ensure  consistency  between  sites 
and  DO's,  and  adherence  to  the  policy  and  procedures  set  forth  in  this  plan,  CM  operations 
are  coordinated  with  the  BDS-D  Manager,  Site  coordinators,  and  the  Loral  ADST  Program 
Office-Orlando. 

A  key  component  of  the  plan  will  be  the  identification  and  establishment  of  the 
common  ADST  software  baseline  as  a  reusable  system  component  as  well  as  identifying 
site  unique  differences.  The  control  mechanisms  described  in  this  plan  serve  as  the 
foundation  of  a  tailorable  standard  applied  to  all  ADST  BDS-D  Delivery  Order  (DO)  efforts 
in  addition  to  ongoing  baseline  maintenance. 
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The  LCXIAL  CM  system  described  in  this  plan  is  based  tqKn  DI-CMAN-80858  and 
MIL-STD-14SdA  as  tailor^  to  the  ADST  program.  Although  the  ADST  program  is  not  a 
MIL-STD  project.  MIZ^STD>1465A  definitions  and  terminology  are  used  dtioughout  this 
document 

Table  2.5-1  shows  the  set  of  Software  Support  Operating  Procedures  being 
proposed  to  supplement  the  CM  plan. 

Table  2.5-1  software  Support  Operating  Procedures 

DOCUMENTS 


ssopm 

TITLE 

SSOP-OOOl 

SSOP  PURPOSE/PROCEDURE 

SSOP-0002 

CONHGURATION  CONTROL  BOARD  (CCB)  CHARTER 

SSOP-0003 

PROBLEM  REPORTING  PROCEDURE 

SSOP-0004 

INTEGRATION  AND  TEST  PROCEDURE  (IN  PROGRESS) 

SSOP-0005 

CODE  CHECKOUT/  FILE  TRANSFER  PROTOCOL  (FTP) 

SSOP-0006 

ADST  LAB  RULES  AND  PROCEDURES 

SSOP-0007 

CM  TURNOVER  PROCEDURE 

SSOP-0008 

REVISION  CONTROL  SYSTEM  (RCS)  HEADER 

COMMENT  STANDARDS 

SSOP-0009 

DELIVERY  ORDER  RELEASE  KITS 

SSOPOOlO 

CM/SDF  BUILD  LOAD  DISTRIBUTIONS 

SSOP-OOllA 

REVISION  CONTROL  SYSTEM  (RCS)  Draft  Update 

SSOP-0012 

VERSION  MASTER  SYSTEM 

SSOP-(X)13 

CHANGE  CONTROL/BUBLD  PR(X:EDURE  FIELD 

SUPPORT 

SSOP-0014 

SP/CR  AUDIT  TRAILS 

SSOP-0015A 

BDS-D  DATA  TRANSFER 

SSOP-(X)16A 

ADST  DOCUMENT  PREPARATION/RELEASE 

SSOP-0017 

ADST  PROPRIETARY  DATA  PROCEDURES 

1 
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3.0  V&V  RESPONSIBILITIES 

This  section  defines  the  agencies  that  have  an  active  part  in  the  V&V  process  along 
with  their  roles  and  responsibilities.  Section  3.1  defines  the  membership  and 
responsibilities  of  the  V&V  Steering  Committee.  Section  3.2  lists  each  participating  party 
and  the  products  which  they  are  responsible  for  verifying.  Section  3.3  lists  each 
participating  party  and  the  products  which  they  are  responsible  for  validating.  Section  3.4 
lists  the  responsibilities  of  the  accrediting  agencies. 

3.1  V&V  Steering  Committee 

Loral  is  the  prime  contractor  responsible  for  the  ADST  ARWA  delivery  order. 
Loral  has  contracted  with  SPARTA  for  a  V&V  effort  of  the  ARWA.  Loral  is  responsible 
for  management,  coordination,  and  technical  direction  of  the  ARWA  team.  As  a  member  of 
the  ARWA  Steering  Committee.  Loral  has  the  following  responsibilities; 

a.  Co-chair  the  ARWA  V&V  Storing  Committee  with  STRICOM. 

b.  Coordinate  the  execution  of  the  V&V  process  with  STRICOM. 

c.  Designate  Loral  representation. 

d .  Ensure  that  the  products  of  the  development  effort  and  the  V&V  process 
meet  the  requirements  of  the  accrediting  agency. 

e .  Provide  the  following  data/effort: 

(1)  Research  and  documentation  of  V&V  based,  existent  software 
models  for  use  by  ARWA  SS. 

(2)  Methodology  to  be  used  (structured  walk-through  techniques),  to 
determine  if  models  and  simulation  will  correctly  perform  the 
intended  functions. 

(3)  Results  of  source  code  inspection. 

(4)  Data  documentation. 

(5)  Configuration  control  documentation. 

(6)  Test  reports. 

(7)  Strawman  V&V  Plan 

f .  Manage  and  coordinate  the  efforts  of  the  ADST  ARWA  DO  team. 
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g.  Provide  additional  assistance  to  the  V&V  Steering  Committee  as 
appropriate. 

SPARTA  is  the  subcontractor  responsible  for  the  V&V  effort  on  the  ARWA  SS 
ADST  delivery  order  managed  by  Loral.  SPARTA  is  not  an  independent  V&V  (IV&V) 
a^nt  As  part  of  the  ARWA  development  team,  SPARTA  must  ensure  that  the  products  of 
the  development  meet  the  V&V  requirements  of  the  accrediting  agency.  SPARTA's  SOW 
defines  the  data  which  SPARTA  must  deliver.  As  a  member  of  the  ARWA  Steering 
Committee,  SPARTA  must  provide  the  following  to  the  committee: 

a.  A  plan  for  the  coordination  and  integration  of  the  Configuration 
Management  and  V&V  Processes,  to  include: 

( 1 )  Haidware/softwaie  requirements  to  support  distributed 
development,  V&V,  and  Configuration  Management. 

(2)  A  schedule  of  software  deliveries  based  on  inputs  from  the  software 
developers  (Loral.  Boeing,  and  MDHC). 

b .  An  identification,  definition,  and  format  of  the  V&V  products. 

c.  An  identification  of  the  data,  models,  and  simulation,  and  processes  used  in 
V&V  and  a  schedule  of  when  those  items  vdll  be  available  based  on  inputs 
from  all  available  sources. 

d .  Proposed  assignments  of  committee  members  to  specific  review  or  analysis 
tasks  and  a  schedule  of  when  those  reviews  or  analyses  must  be  completed. 
These  may  be  provided  on  tl^  scheduled  meeting  dates  or  at  other  times  if 
appropriate. 

Tlie  TSM  Comanche  role  will  be; 

a.  Provide  operational  input  as  required. 

b.  Coordinate  with  TEXCOM  to  identify  AMSAA  funding  requirements  in  the 
FDT  Chitline  Test  Plans. 

c.  Participate  in  validations  at  the  module  integration  level. 

d .  Conduct  validations  of  system  performance  upon  completed  simulator. 

The  TSM  Longbow  role  will  be: 

a.  Provide  operational  input  as  required. 
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b.  Cootdinaie  with  TEXCXDM  tso  identify  AMSAA  funding  lequiieinmts  in  the 
FDT  Outline  Test  Hans. 

c.  Participate  in  validations  at  the  module  integraticm  level. 

d .  Conduct  validations  of  system  performance  upon  completed  simulator. 
AMSAA  will  chair  the  ARWA  sub-committee  on  information  sources  and  models. 


3.2  VERIFICATION 

Lmal  ADST  -  FSM,  VSM.  SSM  Base,  and  Support  Software 

( Operations/Logistics.  A^r  Action  Report,  DIS I/F, 
Mission  Planner,  Session  Manager,  Netwodc  Manager,  and 
Environment) 

SPARTA  -  Ensure  the  verification  of  the  following:  VSM,  FSM,  FSM 
Base,  FSM  Comanche,  FSM  Longbow,  SSM  Base,  Coclq)it  ^ts,  RAH-66 
Comanche  Kit,  RAH-^  Flight  Controls,  RAH-66  Nav/C(xnm,  RAH-66  Weapons, 
RAH-66  Sensors,  RAH-66  ASE,  RAH-^  Flight  Dynamics,  RAH-66  Propulsitxi, 
RAH-66  Physical  Cues,  RAH-66  TNE,  AH-MD  Longbow  Kit,  AH-64D  Flight 
C(xitrols,  AH-64D  Nav/Comm,  AH-64D  Werqxms,  AH-64D  Sensors,  AH-64D 
ASE,  AH-64D  Flight  Dynamics,  AH-64D  Propulsitm,  AH-64D  Physical  Cues,  AH- 
64D  TNE;  Support  Software:  Session  Manager,  Operations  and  Logistics  Support, 
Aviation  Mission  Planner,  After  Acdtrn  Review,  ARWA  LAN,  and  DIS  Network 
Manager. 

AMSAA  -  Models,  documentation,  leads  to  expert  personnel 

Boeing  -  RAH66  Software  Kit 

( Flight  Controls,  Nav/Comm,  Weapons,  Sensors,  ASE, 
Flight  Dynamics,  Physical  Cues,  and  TNE) 

MDHC  -  AH64D  Software  Kit 

( Flight  Controls,  Nav/Comm,  Weapons,  Sensors,  ASE, 
Flight  Dynamics,  and  Physical  Cues) 

Pulau  -  FSM  Ciewstation  Base,  RAH-66  Hardware  Kit,  AH-64D 

Hardware  Kit 


3.3  VALIDATION 


STRICOM  -  Coordinate  validation  activities  and  approve  validation  agencies 
-  Review  and  approve  validation  reports  from  Loral  and  SPARTA 
-TBD 

Loral  ADST  -  Coordinate  validation  activities  among  developers 
-TBD 

SPARTA  -  Ensure  the  validation  of  the  following:  VSM,  FSM,  FSM 
Base,  FSM  Comanche,  FSM  Longbow,  SSM  Base,  Cockpit  Kits,  RAH-6(5 
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Comanche  Kit,  RAH-66  Flight  Controls,  RAH-66  Nav/Comm,  RAH-66  We^^ns, 
RAH-66  SensOTS,  RAH-66  ASE,  RAH-^  Flight  Dynamics,  RAH-66  Propulsion, 
RAH-66  Physical  Cues,  RAH-66  TNE,  AH-64D  Longbow  Kit,  AH-64D  FUght 
Controls,  AH-64D  Nav/Comm,  AH-64D  Wei^xxis,  AH-64D  Sensors,  AH-64D 
ASE,  AH-64D  Flight  Dynamics,  AH-64D  Propulsion,  AH-64D  Hiysical  Cues,  AH- 
64D  TNE;  Support  Software:  Session  Manager,  Operations  and  Logistics  Support, 
Aviation  Mssion  Planner,  After  Action  Review,  ARWA  LAN,  and  DIS  Network 
Manager. 

AMSAA  -  Validated  models 

Boeing  -  Documentation  of  any  validated  models  they  believe  pertinent 

MDHC  -  Documentation  of  any  validated  models  tl^y  believe  pertinent 

3.4  A  CCREDIT  ATION 

STRICOM  -TBD 
Loral  ADST  -TBD 
AMSAA  -TBD 
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4.0  INTENDED  USE  OF  THE  ARWA  SIMULATOR 

A  detailed  description  of  the  defined  purpose  and  expectation  of  the  simulator  will 
Ue  provided  (development,  evaluation  of  and  experimentation  with  tactics  for  "Move,  Shoot 
and  Communicate"). 

The  model  category  and  sub-category  will  be  identified. 

The  problem  that  the  simulator  is  intended  to  solve  will  be  defined  and  specific 
questions  that  the  simulator  is  expected  to  contribute  toward  answering  will  be  included. 

4.1  DEFINED  PURPOSE  AND  Expectation 


4.1.1  Missions 

Each  of  the  ARWA  devices  shall  be  capable  of  performing  the  tasks  identified  in  the 
following  paragraphs  as  applicable  to  each  configuration. 


4.1.1. 1  Flight  Operations 

Flight  operations,  tasks  and  procedures  shall  be  simulated  and  performable  in  the 
ARWA  devices  to  the  level  of  fidelity  defined  herein. 


4.1. 1.1.1  Ground  Operations 

Ground  operations  shall  include  tactical  resupply  and  rearming.  Ground  operations 
do  not  include  engine  start,  engine  run-up,  engine  and  aircraft  shutdown.  Manual  mission 
loading  by  keyboard  entry  or  electronic  media  loading  shall  be  supported.  High  fidelity  taxi 
capabilities  are  not  required. 


4.1 .1. 1 .2  Takcolf  and  Landing 

Simulation  of  the  transition  from  the  ground  environment  to  flight  and  from  flight  to 
the  ground  environment,  including  aerodynamic  ground  effects  shall  be  provided. 


4. 1.1. 1.3  Specific  Flight  Operations 

The  ARWA  devices  shall  provide  the  capability  to  simulate  low  level,  contour,  nap 
of  the  earth,  masking  and  unmasking,  and  hovering  flight  to  the  level  of  fidelity  defined  in 
paragraph  4. 1.1. 2. 


4. 1.1. 2  Mission  Specific  Operations 

The  ARWA  devices  shall  simulate  the  aircraft  functions  needed  to  move,  shoot, 
communicate,  perform  surveillance,  attack,  defend,  rearm,  and  resupply,  to  the  level  of 
fidelity  defined  below: 
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a.  Reconfiguration,  which  includes  cockpit  changeout  and  system 
reintialization  to  a  predetermined  configuration,  but  excludes  parameter 
moditication,  shall  not  require  more  than  sixty  (60)  minutes  to  accomplish. 

b.  Interoperability  with  other  simulators  in  the  network  shall  be  defined  by  the 
Distributed  Interactive  Simulation  (DIS)  protocols  as  extended  by  BDS-D. 

c.  Malfunctions  shall  be  limited  to  those  that  are  a  direct  consequence  of 
simulated  battle  damage.  There  shall  be  no  discretely  selectable  stochastic  or 
operator  insertable  malfunctions.  The  malfunctions  defined  in  Appendix  B 
of  the  System/Segment  Specification  for  the  Advanced  Rotary  Wing  Aircraft 
Simulator  System  Volume  i  shall  be  implemented  as  defined  in  the 
TSA/SFA. 

d.  The  System  shall  be  designed  to  operate  at  the  "system  high"  level  by  the 
document  which  defines  facility  security  policies.  The  capability  to 
declassify  the  System  through  media  removal  and  classified  data  erase 
programs  shall  be  provided.  Classified  data  erase  programs  are  not  required 
for  the  Visual  module  item  and  image  memory. 

e.  Pre-mission  access  to  critical  system  parameters  (e.g.,  weapon  ranges, 
sensor  ranges,  etc.)  shall  be  provided  to  allow  rapid  modification  to  support 
simulator  experiments.  Parameter  modification  shall  not  require 
recompilation  of  source  software  to  implement  changes. 

f.  Simulation  capabilities  to  move,  shoot,  communicate,  rearm,  and  be 
resupplied  in  a  simulated  war  fighting  environment  shall  be  provided. 
Simulation  for  aspects  involving  mission  pre-flight,  start-up,  run-up, 
shutdown,  and  post-flight  procedures  is  not  required. 

g.  Simulation  to  support  equipment  pre-flight,  post  flight,  checkout,  and 
adjustment/calibration  procedures  is  not  required. 

h.  Simulation  of  equipment  operational  characteristics  such  as  power/circuit 
breaker  status,  warm-up  times,  overheat/reset  conditions,  built-in-test, 
delays,  and  failures  induced  by  incorrect  crew  member  procedures  is  not 
required.  Equipment  power-on  status  shall  be  defined  during  pre-mission 
initialization. 

i.  Simulation  of  equipment  interference  effects  caused  by  otiier  onboard 
aircraft  systems  is  not  required. 

j.  The  System  shall  be  capable  of  reporting  its  hardware  and  software 
configuration  to  support  analysis  and  documentation  of  experiments  and  to 
ensure  integrity  of  the  hardware  for  security  reasons. 
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4.2  MODEL  HIERARCHY 

The  ARWA  SS  is  composed  of  the  following  major  components  and  sub 
components. 

VSM 

FSM 

FSMBase 
FSM  Comanche 
FSM  Longbow 
SSMBase 
Cockpit  Kits 

RAH-66  Comanche  Kit 

RAH-66  Flight  Controls 
RAH-66  Nav/Comm 
RAH-66  Weapons 
RAH-66  Sensors 
RAH-66  ASE 
RAH-66  Flight  Dynamics 
RAH-66  Propulsion 
RAH-66  Physical  Cues 
RAH-66  TNE 
AH-64D  Longbow  Kit 

AH-64DHight  Controls 
AH-64D  NavATomm 
AH-64D  Weapons 
AH-64D  Sensors 
AH-64DASE 
AH-64D  Flight  Dynamics 
AH-64D  Propulsion 
AH-64D  Physical  Cues 
AH-64DTNE 
Support  Software 

Session  Manager 

Operations  and  Logistics  Support 

Aviation  Mission  Planner 

After  Action  Review 

ARWA  LAN 

DIS  Network  Manager 

ModSAF 
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4.3  Uses  of  the  simulation 

The  ARWA  SS  is  to  be  used  to  assist  the  Army  in  the  rapid  exploration  of  current 
and  emerging  tactics,  doctrine  and  combat  development  issues.  It  will  be  able  to  perfcum: 

-  single  aircraft  exercises, 

-  team  operations,  and 

-  armed  lecon  and  attack  helicopter  coordination  activities. 

These  will  be  performed  in  real-time  by  reconfigurable  RAH-66  and  AH-64D 
devices,  engaged  in  simulated  warfighting  exercises,  operating  on  the  BattleHeld 
Distributed  Simulation  Development  (BDS-D)  netwo±.  The  simulated  aircraft  will  thus  be 
able  to  realistically  interact  with  each  other,  with  the  terrain  and  cultural  features,  and  with 
external  simulated  forces  in  order  to  simulate  a  tactical  environment  This  environment  will 
permit  the  aircraft  to  perform  realistic  missions  and  flight  operations,  and  give  them  the 
ability  to  employ  all  nav/com  equipment,  sensors,  aircraft  survivability  equipment,  and 
weapons  with  which  they  are  equipped.  All  significant  events  that  occur  during  the 
conduct  of  an  exercise  will  be  logged  for  real-time  and  post-mission  analysis. 
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5.0  INFORMATION  SOURCES 

This  section  identifies  infoimation  sources  relative  to  the  ARWA  V&V  activity; 

Identification  of  the  ARWA  Simulator  documentation.  Requirements 
documents,  System  Specifications.  METL,  TSA,  SFA  study 
documentation, ... 

Identification  of  key  personnel  who  participated  in  the  development  of  the 
simulator.  Develo^rs,  proponents. ... 

Identification  of  the  SME’s  or  other  personnel  who  will  define  the  "real 
world"  relative  to  the  ARWA  simulator. 

Identification  of  the  "real  world"  data  points  for  use  as  comparative  data. 


5.1  Loral 

5.2  Boeing 

5.3  MDHC 

5.4  STRICOM 

5.5  COMANCHE  TSM 

5.6  Longbow  TSM 

5.7  AMSAA 

5.8  SPARTA  Defined  Sources 


5.8.1  RAH-66  RELATED  INFORMATION 

SPARTA  will  assemble  and  review  the  following  documents  prior  to  performing 
verification  and  validation  activities  on  the  RAH-66  simulator; 

1 .  System/Segment  Specification  for  the  RAH-66  Simulator  System  Module 

(Sxxx-xxxxx) 

2 .  Software  Requirements  Specification  For  The  Flight  Dynamics  Segment  Of 

The  ARWA  RAH-66  Simulator  System  Module  (S567-XXXXX) 

3 .  Software  Requirements  Specification  For  The  Flight  Controls  Segment  Of 

The  ^WA  RAH-66  Simulator  System  Module  (S567-XXXXX) 

4 .  Segment  Design  Document  For  The  RAH-66  Flight  Control  System 

(2000-741-500) 

5 .  Software  Requirements  Specification  For  The  Primary  Flight  Control 

Processor  Of  The  RAH-66  Comanche  Flight  Control  System 
(2000-744-001) 
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6 .  Primary  Flight  Control  Processor  Software  Vendor  Drawings 

(2000-744-001) 

7 .  Software  Requirements  Specification  For  The  Automatic  Flight  Control 

Processor  Of  The  RAH-66  Comanche  Flight  Control  System 
(2000-744-002) 

8 .  Automatic  Flight  Control  Processor  Software  Vendor  Drawings  ( 

2000-744-002) 

9 .  Software  Requirements  Specification  For  The  Flight  Director  Of  The 

RAH-66  Comanche  Flight  Control  System  (2000-744-5(X)) 

1 0.  Software  Requirements  Specification  For  The  Propulsicm  Segment  Of  The 

ARWA  RAH-66  Simulator  System  Module  (SS67-XXXXX) 

1 1 .  Software  Requirements  Specification  For  The  Object  library  (OL)  Of  The 

RAH-66  Comanche  Flight  Control  System  (2000-744-503) 

12.  Boeing-Helicopter  BH-SIM  Flight  Controls  Code,  Drawings  and 

Documentation 

1 3.  Pilot- Vehicle  Interface  Mechanizmion  Specification  RAH-66  Comanche 

2000-730-002B) 

1 4.  Block  2  Pilot  Vehicle  Interface  Mechanization  Specification 

(2000-730-002B) 

15.  Air  Vehicle  Preliminary  Design  Report  (2000-3 10-003) 

16.  APPENDIX  A  RAH-66  Comanche  Switches,  Controls  and  Displays, 

Selecdve  Fidelity  Charts 

1 7 .  Configuration  Item  Development  Specification  For  The  Comanche  Cyclic 

And  Collective  Control  Grips  (2000-745-004) 

18.  T800  Engine  Data  from  Maj.  Ochsner 

19.  Advanced  Distributed  Simulation  Technology  Rotary  Wing  Aircrafi  Step  1 

Rnal  Report  (D567-30991) 

20.  Advanced  Rotary  Wing  Aircraft  RAH-66  Task  and  Skills  Analysis  And 

Selective  Fidelity  Analysis  Block  2  Revision  1.0 
(L-E-91-129-10-93) 

21.  SH-60F(CV-HELO)  Listings  aiQ4107-l) 

22.  SH-60F  (CV-HELO)  Program  Design  SpecificaUon  (HQ4107-2) 

23 .  SH-60F  (CV-HELO)  Math  Models  (HQ4 107-3) 

24.  RAH-66  Weight  and  Balance  Status  Report  No.  9  (2000-1 14-012) 

25.  Boeing-Hcllcopter  BH-SIM  Flight  Code,  Drawings  and  Documentation 


5.8.2  AH-64D  RELATED  INFORMATION 

The  following  documents  are  not  currently  available  for  the  AH-64D.  However, 
these  documents  or  ones  which  contain  similar  information  should  be  available  after  the 
associated  development  phase. 

1 .  System/Segment  Specification  for  the  AH-64D  Simulator 

2 .  Software  Requirements  Specification  For  The  Flight  Dynamics  Segment  Of 

The  AH-64D  Simulator 
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3.  Software  Requiiments  Specification  Fot  The  Flight  Controls  Segment  Of 

The  AH-64D  Simulaux- 

4.  Segment  Design  Document  For  The  AH-64D  SimulattM-  Flight  Contnd 

System 

5 .  Software  Requirements  Specification  For  The  Primary  Flight  Contrtd 

Processor  Of  The  AH-64D  Sirnulamr 

6.  Software  Requirements  Specification  Fbr  The  Flight  DirecttMT  Of  The 

AH-MD  Simulator 

7.  Software  Requirements  Specification  For  The  Object  Library  (OL)  Of  The 

AH-^D  Simulator 

8 .  Software  Requirements  Specification  For  The  Propulsion  Segment  Of  The 

AH-MD  Simulator 

The  following  documents  have  previously  been  identified  as  sources  of  information 
on  the  AH-64D. 

9 .  ARMY  Airspace  Command  and  Control  in  a  Combat  Zrnie,  Y,  10/07/87, 

FM  100-103,  SIMNET 

10.  Field  Manual  -  Air  Assault  Operations,  ?,  03/16/87,  FM  90-4,  SIMNET 

1 1 .  Field  Manual  -  Air  Combat  Gyrations  Approved  Final  Draft,  Y,  06/01/89, 

FM  1-107,  SIMNET 

1 2.  Field  Manual  -  Aircraft  Battlefield  Countermeasures  and  Survivability, 

06/01/89,  FM  1-101,  SIMNET 

13.  Field  Manual  -  Attack  Helicopter  BattaUon,  Y,  07/14/86,  FM  1-1 12, 

SIMNET 

14.  US  Army  Air  Defense  Artillery  Employment,  Change  I Y,  08/28/84, 

FM  44-1,  SIMNET 

1 5.  APACHE  Pictorial  Reference  Book,  Y,  06/01/85,  SIMNET 

16.  Operator's  Manual  for  Army  AH-64A  Helicopter,  Change  18, 08/29/90, 
TM-55- 1520-238- 10,  lEI 

17.  US  Army  Aviation  Center  AirNet  Standing  Operating  Procedure  (SOP),  ?, 
SIMNET 

1 8 .  SIMNET  Ethernet  Performance,  Y,  SIMNET 

19.  Instructor  Guide,  AH-64  Cockpit  Weapons  Emergency  Procedure  Trainer 

(CWEPT)  (Copilot/Gunner),  Y,  02/01/89, 15-6454-7.5, 

B.  Crabtree 

20.  Instructor  Guide  -  AH-64  SWEFf  (PUot),  Y,  03/01/89, 156452-7.5, 

B.  Crabtree 

2 1 .  Mission  Training  Plan  for  the  Attack  Helicopter  Company,  Y,  05/18/89, 

ARTEP-1-187-30-MTP,  SIMNET 

22.  Lesson  Plan  -  AH-64A  Avionics  and  Doppler,  Y,  01/01/88, 33-0295-2, 

SIMNET 

23.  Lesson  Plan  -  AH-64H  Operating  Limits/Flight  Characteristics,  01/01/90, 

15-6427-3,  SIMNET 

24.  Student  Handout  -  AH-64A  Operating  Limits/Flight  Characteristics. 

03/01/89, 15-6427-3,  SIMNET 
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25.  Lesson  Plan  -  AH-64  UtiUty  System,  Y.  01/01/90. 15-6428-2,  SIMNET 

26.  Student  Handout  -  AH-64  UtiUty  System.  Y.  10/01/87, 15/32/33-6428-2, 

SIMNET 

27.  Lesson  Plan  -  AH-64A  FUght  Controls,  Y,  01/01/90, 15-6429-2,  SIMNET 

28.  Student  Handout  -  AH-54A  FUght  Controls,  Y.  07/01/87, 15/32/33 

6429-2,  SIMNET 

29.  Lesson  Han  -  AH-64A  Digital  Autmnatic  Stabilization  Equipment  (DASE), 
02A)l/88, 15/33-6430-2.5.  SIMNET 

30.  Student  Handout  -  AH-64A  Digital  Automatic  StabiUzation  Equipment 

(DASE).  Y.  02/01/88, 15/33-6430-2.5,  SIMNET 

3 1 .  Usson  Plan  -  AH-64A  Multiplex  System.  Y,  01/01/88, 15/33-6431-1, 

SIMNET 

32.  Student  Handout  -  Multiplex  System  (MUX).  01/01/86, 15/32/33-6431-1, 

SIMNET 

33 .  Lesson  Han  -  AH-64A  Fault  Detection/Location  System  (FD/LS), 

01/01/88, 15/33-6432-2,  SIMNET 

34.  Student  Handout  -  AH-64A  Fault  Detection/Location  System  (FD/LS), 

01/01/88, 15/33-6432-2,  SIMNET 

35.  Lesson  Plan  -  AH-64A  Avionics,  Y,  01/01/89, 15-6433-3,  SIMNET 

36.  Student  Handout  -  AH-64A  Avionics.  Y,  01/01/89, 15-6433-3,  SIMNET 

37 .  Lesson  Plan  -  AH-64A  Area  Weapon  System  (AWS),  04/01/88, 

15-6440-2.  SIMNET 

38.  Student  Handout  •  AH-64A  Area  Weapon  System  (AWS),  04/01/88, 

15-6440-2,  SIMNET 

39.  Lesson  Plan  -  AH-64A  Aerial  Rocket  Control  System  (ARCS),  03/01/88, 

15-6442-2.5,  SIMNET 

40.  Student  Handout  -  AH-64A  Aerial  Rocket  Control  System  (ARCS), 

03/01/88, 15-6442-2.5,  SIMNET 

4 1 .  Lesson  Plan  -  Point  Target  Weapon  System,  Y,  09/01/89, 15-6443-6, 

SDiiNET 

42.  ■  Student  Handout  -  Point  Target  Weapon  System,  Y,  05/01/88, 15-6443-6. 

SIMNET 

43.  Lesson  Plan  -  Introduction  to  the  AH-64A,  Y,  07/01/89, 15-6415-1, 

SIMNET 

44.  Student  Handout  -  Introduction  to  the  AH-64A,  Y,  01/01/88, 

15/33-6415-1,  SIMNET 

45.  Lesson  Plan  -  AH-64  Airframe  and  SurvivabiUty,  Y,  06/01/89, 15-6416-2, 

SIMNET 

46.  Student  Handout  -  AH-64  Airframe  and  Survivability,  Y,  03/01/88, 

15-6416-2,  SIMNET 

47.  Lesson  Plan  -  AH-64  Caution  and  Warning  System,  Y,  08/01/89, 

15-6417-1.  SIMNET 

48.  Student  Handout  -  AN/ASN  Doppler  Navigation  Set  (DNS),  Y,  06/0 1/89, 

15/33-0311-4,  SIMNET 

49.  Student  Handout  -  FLIR  Imagery  Interpretation,  Y,  03/01/88, 15-6405-1, 

SIMNET 
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50.  Student  Handout  -  Aircraft  Survivability  Equipnunt,  Y,  08/01/88. 

3K/4A/4G/4H/4L/15/3 1/33-1888-3,  SIMNET 

5 1 .  Student  Handout  -  Infrared  (IR)  Theory  and  Modular  Forward  Looking 

Infrared  (FUR)  Components,  Y.  03/01/88, 15-6462-2,  SIMNET 

52.  Student  Handout  -  AH-64  Pilot  Symbology,  Y.  12/01/88, 15-6464-3, 

SIMNET 

53 .  Aircrew  Training  Manual  -  Atuu:k  Helicq)ter,  AH-64.  Y,  05/3 1/86, 

FC  1-214,  B.  Crabtree 

54.  Program  of  Instruction  -  AH'64  Aviator  (^ualiHcation  Course,  Y.  01/01/88, 

2C-SUI1L/2C-152F,  B.  Crabtree 


5.8.3  SPARTA'S  ARWA  LIBRARY 

SPARTA  currently  has  assembled  and  will  utilize  the  following  documents  in 
performing  verification  and  validation  activities  on  the  ARWA  Simulator  System: 

1 .  SPARTA  Proposal  LRL02B,  Universal  Threat  System  for  Simulators 

2.  System/Segment  Specification  for  Generic  Modular  Simulator  Vols  8-12, 

14  and  ^pendix  A 

3 .  SMART  Briefing 

4.  Modular  Simulator  Executive  Report,  8/25/933oeing  (D495-10441-1) 

5 .  ARWA  Briefing  -  LADS  Orlando  Operation,  10/24/93,  LORAL 

6  The  Use  of  Pilot  Rating  in  the  Evaluation  of  Aircraft  Handling  Qualities, 

4/1/69,  Ames  Research 

7 .  Prototype  AH-64  Simulator  (Draft) 

8 .  Systera/Segment  Specification  for  Generic  Modular  Simulator 

Vols.  I  thru  VU.  2/4/93,  Boeing  (S495-10400C) 

9 .  System/Segment  Specification  for  Rotary  Wing  Aircraft  Simulator  System 

(Draft),  10/4/93,  Boeing 

10.  Anti-Armor  Advanced  Technology  Demonstration  (A2ATD)  D.O.,  9/27/93, 

IGRAT, 

1 1 .  Executive  Summary  of  AMSAA  Trip  Report,  4/2/93,  LOARL 

1 2.  The  ARWA  V&V  Steering  Committee  .Meeting  1, 1 1/1/93,  SPARTA 

1 3 .  LORAL  ARWA  V&V  Program  Management  Review  -  Briefing,  9/23/93, 

SPARTA 

14.  ARWA  Program  Management  Review  No.  1  September  22-23,1993, 

LORAL 

1 5 .  Close  Combat  Tactical  Trainer  Data  Structures,  Algorithms,  and  Generic 

System  Mapping,  5/1/93 

16.  RAH-66  Task  and  Skills  Analysis  and  Selective  Fidelity  Analysis,  2/1/92, 

LORAL 

17.  ARWA  V&V  RFP/SOW  Volume  1,  LORAL 

18.  ARWA  PMR  #1  Minutes  9/22/93 

19.  Distributed  Interactive  Simulation  Common  Database  Standard 

20.  Battlefield  Distributed  Simulator  -  Developmental  (BDS-D  Model  V&V  & 

Accreditation  Plan 
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94-003282  April  15,  1994 

Re^)oose  to  Action  Item  #4  fonn  V&V  steering  CommittBc  >feeting  #1 
Pie^inaiy  Design  Review  (PDR)  Piesoitation  Package  for  Subcontractor 
Strawman  V&V  Plan  (Phase  1) 

Model  List  for  ARWA.  11/1(V93.  LORAL 
MDHC  ARWA  Schedule  (Revision  1).  1 1/1/93 
Boeing  Simulate  System  Module  StAedule.  6/3/93,  Boeing 
And-Armor  Advanced  Technology  Demonstration  (A2ATD) 

V&V  Technical  Vobmie  f<v  E9q)eriment  1  Anti-Armw  Advanced 
Technotegy  Demonstration  (A2ATD) 

The  Vmfication  and  Validation  Plan  Status,  12/03/93 
V&V  Steering  Committee  Meeting  2, 12/02/93 

RWA  Engineering  Design  Review-1  &  Design  Criteria  Conference.  2/27/92 
Advanced  Development  Model  Air  Tactics,  Tactical  Envirraunent 
Modeling,  Data  Requirements,  and  Resources 
Concise  Guide  to  Issue/  Discrepancy  Analysis  and  Tracking 
S/W  Requirement  Specification  -  Aircraft  SurvivabiliQr  Equipment  Segment 
of  the  ARWA  RAH-66  Simulator  System  Module,  1 1/24/93, 

Boeing  (S567-XXXXX) 

S/W  Requirement  Specification  -  Control  Segment  of  the  ARWA  RAH-66 
Simulator  System  Module.  1 1/24/93,  Boeing  (S567-XXXXX) 

S/W  Requirement  Specification  -  Environment  Segment  of  the  ARWA 
RAH-66  Simulator  System  Module,  11/24/93,  Boeing 
(S567-XXXXX) 

S/W  Requirement  Specification  -  Flight  Dynamics  Segment  of  the  ARWA 
^H-66  Simulator  System  Module,  1 1/24/93,  Boeing 
(S567-XXXXX) 

S/W  Requirement  Specification  -  Navigation/Communication  Segment  of 
the  ARWA  RAH-66  Simulaux^  System  Module.  1 1/24/93,  Boeing 
(S567-XXXXX) 

S/W  Requirement  Spedficadon  -  Physical  Cues  Segment  of  the  ARWA 
RAH-66  Simulator  System  Module,  1 1/24/93,  Boeing 
(S567-XXXXX) 

S/W  Requirement  Specification  -  Propulsion  Segment  of  tiie  ARWA 
RAH-66  Simulator  System  Module,  1 1/24/93,  Boeing 
(S567-XXXXX) 

S/W  Requirement  Specification  -  Sensors  Segment  of  the  ARWA  RAH-66 
Simulator  System  Module,  1 1/24/93,  Boeing  (S567-XXXXX) 

S/W  Requirement  Specitlcation  -  Weapons  Segment  of  the  ARWA  RAH-66 
Simulator  System  Module,  1 1/24/93,  Boeing  (S567-XXXXX) 

S/W  Requirement  Specification  -  Flight  Controls  Segment  of  the  ARWA 
RAH-66  Simulator  System  Module,  1 1/24/93,  Boeing 
(S567-XXXXX) 

Advanced  Distributed  Simulation  Technology  Rotary  Wing  Aircraft, 

11/24/93,  Boeing  (D567-30991) 

Army  Model  and  Simulation  Management  Program,  6/10/92,  HQ  Dept,  of 
the  Army 
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5.8.4  Model  documentation  Library 

SPARTA  currently  has  assembled  and  will  utilize  the  following  model 
documentation  in  performing  verification  and  validation  activities  cm  the  ARWA  Simulator 
System; 

1 .  Air  Defense  Air-to-Ground  Engagement  (ADAGE)  Simulation,  Volume  n, 

The  Incursion  Model,  May  1978,  AMSAA  Technical  Report 
Number  227,  U.S.  Army  Material  System  Analysis  Activity 

2 .  Low  Energy  Laser  Weapon  Simulation  (LELAWS)  Volume  I  -  Analyst's 

Manual.  27  March  1987,  SPARTA  Inc. 

3 .  Low  Energy  Laser  Weapon  Simulation  (LELAWS)  Volume  n  -  User's 

Manual,  30  December  1986,  SPARTA  Inc. 

4 .  C2NVED  Thermal  Imaging  Systems  Performance  Module  FLIR90, 

18  May  1990,  U.S.  Army  CECOM  Center  for  Night  Vision  & 
Electro-optics,  FT.  Belvoir,  VA 

5 .  C2NVED  Thermal  Imaging  Systems  Performance  Module,  18  May  1990, 

U.S.  Army  CECOM  Osnter  for  Night  Vision  &  Electro-optics, 

FT.  Belvoir,  VA 
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6.0  VERIFICATION  AGENDA 

The  logic  and  code  verification  procedures,  products,  and  data  requirements  described 
below  represent  the  complete  set  of  activities  that  would  be  performed  for  V&V  Intensity 
Level  1.  The  specific  Iq^c  and  code  verification  activities  to  be  performed  for  each  ARWA 
SS  component  are  deflned  in  Section  6.3. 

The  following  is  an  outline  of  the  verification  activities: 

*  Logic  verification 

-  Library  development 

-  Documentation  Review 

-  Design  Walk-Throughs 

-  Flow  Diagram  Reviews 

-  Algorithm  Checks 

-  Comparison  of  Pseudo-code  to  the  Design  Specifications 

-  Logic  Representation 

•  Code  verification 

-  Code  Walk-Throughs 

-  Peer  Review 

-  Units  Check 

-  Logic  Representation 

-  Sensitivity  Analysis 

-  Statistical  Tests  for  Stochastic  Models 


6. 1  Logic  Verification  methodology 

The  following  sections  describe  the  activities  required  to  verify  the  logic  of  the 
segment  design.  The  purpose  of  these  activities  is  to  ensure  that  the  design  correctly  meets 
the  requirements.  When  possible  the  logic  should  be  verified  prior  to  the  start  of  coding. 


6.1.1  Library  Development 

The  ARWA  V&V  team  will  identify  and  assemble  all  key  documentation  required  to 
perform  the  verification  and  validation  ta.sks.  These  will  include  ARWA  SS  specification 
and  design  documents,  as  well  as  reference  “truth”  documents  that  will  primarily  be  used  in 
the  validation  phase. 


6.1.2  Documentation  Review 

The  verification  team  will  make  a  thorough  review  of  all  design  and  specification 
documents  to  gain  a  clear  understanding  of  what  the  requirements  are  for  each  software 
segment  and  functional  elements  of  it.  These  comprise  the  basic  criteria  upon  which  the 
verification  process  is  based  and  will  be  well  documented  in  the  verification  and  validation 
(V&V)  report. 
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The  documents  to  be  reviewed  include,  but  are  not  limited  to,  the  System/Segment 
Specification  (SSS),  the  Software  Requirements  Specification  (SRS),  and  the  Interface 
R^uirements  Specification  (IRS). 

The  SSS  will  be  compared  against  tl^  ARWA  SS  technical  requirements  document 
A  traceability  matrix  will  be  constructed  to  map  requirements  into  the  lower  level 
documents.  Any  discrepancies  will  be  noted  in  the  discrepancy  and  problem  tracking  data 
base  maintained  by  the  CCB.  The  SRS  and  IRS  will  be  compared  to  the  SSS  to  assure  that 
all  specifications  have  been  addressed  and  that  no  software  or  interface  requirement  exits 
which  cannot  be  matched  to  a  corresponding  specification.  This  traceability  information 
will  also  be  input  to  the  V&V  documentation  to  support  further  traceability  efforts.  Any 
discrepancies  will  be  noted  in  the  discrepancy  and  problem  tracking  data  base  maintained 
by  the  CCB. 

6. 1.2.1  Pre*PDR  Phase 


Data  Sources 

Table  6.1.2. 1-1  describes  the  data  sources  that  can  be  used  during  the  Pre-PDR 

phase. 


Title 

Description 

Format 

Guide 

Source 

Associated 

Procedure 

System/ 

Segment 

Specification 

Functional  allocation  of 
technical  requirements  to 
various  system 
configuration  items 

TEI5 - 

(DI- 

CMAN- 

80008A) 

Ciov't  - 

Functional 

Baseline 

X5 - 

Software 

Requirements 

Specification 

Draft- 

Developer, 

Final 

1,2 

Interface 

Requirements 

Sp^ification 

TBD 

(DI- 

MCCR- 

80026A) 

Draft- 
Developer, 
Final-  Gov't 
Allocated 
Baseline 

i,i 

Developers 
Contract  SOW, 
Format  Guide 
and  tailored 

DIDs 

Document  Format  and 
Content  Requirements 

■RTa 

Cjov’t 

1,2 

Table  6. 1 .2. 1- 1  Pre-PDR  Phase  Verification  Data  Sources 


Procedures 

The  following  paragraphs  describe  the  procedures  that  can  be  used  during  the  Pre- 
PDR  phase. 
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1.  Review  Software  and  Interface  Requirements  Si^ifications  against  the  Systems 
Segment  Specificatitm  to  assure  that  all  specifications  have  been  addressed  and  that 
no  software  or  interface  requirement  exists  which  can  not  be  matched  to  a 
corresponding  specification.  Enter  this  traceability  information  in  the  V&V 
documentation  to  support  further  traceability  efforts  at  the  software  design 
document  level.  Enter  any  discrepaiKnes  into  the  discrepancy  and  problem  tracing 
data  base  maintained  by  the  CCB.  Produce  V&V  Plan  identifying: 

•  Higher  level  requirements  which  are  not  addressed, 

•  Software  and  Interface  requirements  which  are  not  traceable  to  a  higher- 
level  specification. 

•  Format  and  content  discrepancies, 

•  Requirements  which  are  untestable  and/or  unambiguous. 

2.  Support  Reviews  and  Audits  by: 

•  Providing  briefmg  material  containing  summary  status  information  for  each 
critical  module.  Summary  information  will  include  software  size  estimates, 
schedule  (planned  versus  actual),  and  action  items  to  be  addressed  during 
the  meeting, 

•  Participating  in  the  review  as  directed  by  the  Prime. 


Products 

Table  6. 1.2. 1-2  defines  the  V&V  products  of  the  Pre-PDR  phase. 


Title 

Description 

Format 

Guide 

Frequency 

ViV  Plan 

Report  on  the  completeness  of 
the  Systems/Segment 
Specification  (from  the  software 
perspective) 

Initial  one 
-time,  update 
as  required  by 
ECPs  affecting 
the  SSS 

■■1 

Report  on  the  completeness  of 
the  Software  Requirements 
Specification  (one  per  Module) 

TBD 

1 _ 

Once  per 
Module 

V&V  Plan 

Report  on  the  completeness  of 
the  interface  requirements 
specification  (one  per  Module) 

Once  per 
Module 

Table  6.1.2. 1-2  Pre-PDR  Phase  Verification  Products 


The  V&V  Plan  will  contain  the  following  results  of  the  Pre-PDR  activities: 

*  Requirements  that  are  not  addressed 

*  Requirements  which  can  not  be  matched  to  a  higher  level  specification 

*  Requirements  in  the  SSS  not  previously  identified  in  the  technical 
requirements  document  or  other  early  requirements  documents 

*  Higher  level  requirements  which  are  not  addressed 

*  Software  and  Interface  requirements  which  are  not  traceable  to  a  higher- 
level  specification 
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•  Requirements  which  are  untestabie  and/or  ami^ous 

•  Format  and  content  discrepancies 


6. 1.2. 2  PDR  Through  CDR  Phase 

Data  Sources 

Table  6.1.2.2-1  describes  the  data  sources  that  can  be  used  from  PDR  through  the 
CDR  I^iase. 


Title 

Description 

Format 

Gnide 

Source 

Associated 

Procednre 

Software 

Design 

Documents 

(Preliminary) 

TSD 

(DI- 

MCCR- 

80012A) 

i.5 

Specifies  the  preliminary 
d^gn  of  one  or  more 
interfaces  between  CSCI(s). 

mSBM 

■ 

m 

Software 

Design 

Dociments 

(Detailed) 

TBD 

(DI- 

MCCR- 

80012A) 

H 

Interface  Design 

Documents 

(Detailed) 

mill 

Tftb 

(DI- 

MCCR- 

80027A) 

Defines  the  software  test 
environment  resources 
required,  the  schedule  of  test 
activities,  and  the  individual 
test  to  be  performed. 

TUd 

(DI- 

MCCR- 

80014A) 

2,3 

Developers 
Contract  SOW, 
Format  Guitte 
and  tailored 

DIDs 

Document  Format  and 
Content  Requirements 

■RTa 

Gov't 

T53 

Table  6. 1 .2.2- 1  PDR  Through  CDR  Phase  Verification  Data  Sources 


Procedures 

The  following  paragraphs  describe  the  procedures  that  can  be  used  from  PDR 
through  the  CDR  Phase. 

1.  Review  Detailed  Software  and  Interface  Design  Documents  against  the  Preliminary 
Software  and  Interface  Design  Documents  as  well  as  the  Software  and  Interface 
Requirements  Specification.  The  goal  as  before  is  to  assure  that  all  requirements 
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have  been  addressed  and  that  no  software  or  interface  design  feature  exists  which 
can  not  be  matched  to  a  corresponding  requirement.  Enter  this  traceability 
information  in  the  V&V  documentation  to  support  further  traceability  efforts  at  the 
coding  and  unit  test  level.  Enter  any  discrepancies  into  the  discrepancy  and 
problem  tracking  data  base  maintained  by  the  CCB.  Identify  the  following  in  the 
V&VPlan: 

•  Requirements  which  are  not  addressed, 

•  Software  and  Interface  design  features  which  do  not  support  a  higher-level 
requirement. 

•  Format  and  content  discrepancies. 

2.  Review  Software  Test  Plan  against  the  Software  and  Interface  Requirements 
Specification.  The  software  Test  Plan  defines  the  formal  qualification  tests  for  the 
CSCI,  the  software  test  environment  resources  required,  the  schedule  of  activities, 
and  the  individual  test  to  be  performed.  The  goal  of  this  review  is  on  the 
idenUfication  of  test  which  will  provide  objective  evidence  that  the  CSCI  meets  its 
requirements.  Enter  this  traceability  information  in  the  V&V  documentation  to 
support  further  traceability  activities  at  the  coding  and  unit  test  level.  Enter  any 
di^repancies  into  the  discrepancy  and  problem  tracking  data  base  maintained  by 
the  CCB.  Identify  the  following  in  the  V&V  Plan: 

•  Requirements  for  which  no  test  is  identified, 

•  Tests  identified,  but  for  which  a  requirement  cannot  be  identified, 

•  Level  and  type  of  testing  to  be  performed  to  satisfy  each  requirement, 

•  Format  and  content  dis^pancies. 

3.  Support  Reviews  and  Audits  by : 

•  Providing  briefing  books  containing  summary  status  information  for  each 
critical  CSCI.  Summary  information  will  include  software  size  estimates, 
schedule  (planned  versus  actual),  and  action  items  to  be  addressed  during 
the  meeting, 

•  Participating  in  the  review  as  directed  by  the  Prime. 

Products 

Table  6.1. 2.2-2  defines  the  V&V  products  from  PDR  through  the  CDR  Phase. 


Title 

Description 

Format 

Guide 

Frequency 

■1 

Report  on  the  completeness  of 
the  Preliminary  Software  Design 
Documents  (one  per  module) 

TBD 

Once  per 
module 

V&V  Plan 

Briefmg  materials  reflecting  the 
status  of  each  modules 

TBD 

Once  per 
module 

Table  6. 1 .2.2-2  PDR  Through  CDR  Phase  Verification  Products 
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The  V&V  Plan  will  contain  the  follovinng  results  from  PDR  through  the  CDR 

Phase: 

•  Preceding  requirements  (higher  level)  which  are  not  addressed 

•  Preliminary  software  design  and  Interface  design  features  which  do  not 
support  a  higher-level  requirement 

•  Requirements  which  are  not  addressed 

•  Software  and  Interface  design  features  which  do  not  support  a  higher-level 
requirement 

•  Requirements  for  which  no  test  is  identified 

•  Tests  identified,  but  for  which  a  requirement  cannot  be  identified 

•  Level  and  type  of  testing  to  be  performed  to  satisfy  each  requirement 

•  Format  and  content  discrepancies 

6. 1.2.3  Post  CDR  Phase 
Data  Sources 

Table  6. 1.2.3- 1  describes  the  data  sources  that  can  be  used  during  the  Post-CDR 

Phase. 


-33- 


ADST/TR  94-003282 


April  15,  1994 


ottwaie  Test 
Descriptions 


Developers 
Contract  SOW, 
Format  Guide  and 
tailored  DIDs 


mes  the  software  test 
environment  resources 
required,  the  schedule  of 
activities,  and  the  individual 
test  to  be  performed. 


ines  the  test  cases  and 
procedures  needed  to 
perform  formal  qualification 
testing  of  a  CSCI  in 
accordance  with  the  STP. 


Serves  as  a  record  of  the 
formal  quartficatioii  testing 
performed  on  a  CSCI. 


Document  Format  and 
Content  Requirements 


Table  6. 1 .2.3- 1  Post  CDR  Phase  Verification  Data  Sources 
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Procedures 

The  following  paragraphs  describe  the  procedures  that  can  be  used  during  the  Post- 
CDR  Phase. 

1.  Review  Detailed  Software  and  Interface  Design  Documents  during  Coding,  CSU 
Testing,  CSC  Integration,  and  Testing  phases.  This  review  compares  the  SDD 
and  IDD  products,  while  they  are  evolving  in  the  contractor  controlled 
Developmental  Configuration,  against  the  Software  and  Interface  Requirements 
SpeciHcation  to  assure  that  all  requirements  continue  to  be  addressed  and  that  no 
software  or  interface  design  feature  exists  which  can  not  be  matched  to  a 
correspon^ng  requirement  Enter  this  traceability  information  in  the  V&V 
documentation  to  support  further  traceability  efforts  as  these  SDD  and  IDD  are 
updated.  Enter  any  discrepancies  into  the  discrepancy  and  problem  tracking  data 
b^  maintained  by  the  CCB.  Identify  the  following  in  the  V&V  Plan: 

•  Requirements  which  are  not  addressed  by  design, 

•  Software  and  Interface  design  features  which  do  not  support  a  higher-level 
requirement, 

•  Format  and  content  discrepancies  based  on  the  contractor  specified  format 

2.  Review  Source  Code  against  the  Detailed  Software  and  Interface  Design 
Documents  as  well  as  the  Software  and  Interface  Requirements  Specification 
during  Coding,  CSU  Testing,  CSC  Integration,  and  Testing  phases.  The  goal  as 
before  is  to  assure  that  all  requirements  have  been  addressed  and  that  no  software 
or  interface  design  feature  is  imptemented  in  the  code  which  can  not  be  matched  to 
a  corresponding  requirement.  Enter  any  discrepancies  into  the  discrepancy  and 
problem  tracking  data  base  maintained  by  the  CCB.  Identify  the  following  in  the 
V&V  Plan: 

•  Requirements  which  are  not  addressed  by  code, 

•  Software  and  Interface  code  fetuures  which  do  not  support  a  requirement,  or 
trace  directly  to  design, 

•  Non-adhercnce  to  the  contractor’s  software  standards  and  procedures 
format  and  content  requirements. 

3.  Review  Software  Test  Descriptions  against  the  Software  and  Interface 
Requirements  Specification  and  against  the  Software  Test  Plan.  The  software  test 
descriptions  begin  by  defining  test  cases  prior  to  CDR  and  continue  to  be  further 
refined  by  defining  the  test  procedures.  The  goal  of  this  review  is  similar  to  the 
preceding  reviews,  however  wc  are  focusing  on  the  identification  of  the  specific 
test  cases  and  detailed  procedures  which  will  provide  complete  and  objective 
evidence  that  the  CSCI  meets  its  requirements.  Enter  this  traceability  information 
in  the  V&V  documentation  to  support  further  traceability  activities.  Enter  any 
discrepancies  into  the  discrepancy  and  problem  tracking  data  base  maintained  by 
the  CCB.  Identify  the  following  in  the  V&V  Plan: 

•  Requirements  for  which  no  test  is  identified, 

•  Tests  identified,  but  for  which  a  requirement  cannot  be  identified, 

•  Format  and  content  discrepancies. 

4.  Review  Detailed  Software  and  Interface  Design  Documents.  This  review  compares 
the  SDD  and  IDD  products  against  the  Software  and  Interface  Requirements 
Specification  to  assure  that  all  requirements  have  been  addressed  and  that  no 
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software  or  interface  design  feature  exists  which  can  not  be  matched  to  a 
corresponding  requirement  Enter  this  traceability  information  in  the  V&V 
documentation.  Enter  any  discrepancies  into  the  discrepancy  and  problem  tracking 
data  base  maintained  by  the  CCB.  Identify  the  following  in  the  V&V  Plan; 

•  Specifications  which  are  not  addressed. 

•  Software  and  Interface  design  features  which  do  not  support  a  higher-level 
requirement 

•  Format  and  content  discrepaiuries. 

5.  Review  Software  Test  Reports  against  the  Software  and  Interface  Requirements 
Specification  and  against  the  Software  Test  Plan  and  Software  Test  Descriptions. 
The  STR  is  reviewed  for  test  completeness,  insuring  that  all  planned  tests  and 
procedures  are  documented  with  r^ults.  The  goal  of  this  review  is  to  determine 
that  all  tests  were  exercised  or  explanations  are  present  and  that  the  results 
inovided  sufficient  objective  evidence  that  the  CSCI  meets  its  requirements.  Enter 
this  traceability  information  in  the  V&V  documentation.  Enter  any  discrepancies 
into  the  discrepancy  and  problem  tracking  data  base  maintained  by  the  CCB. 
Identify  the  following  in  the  V&V  Plan: 

•  Requirements  for  which  no  test  is  reported, 

•  Tests  identified,  but  for  which  a  requirement  cannot  be  identified, 

•  Test  results  which  do  not  support  tte  objectives  of  the  STP  and  STDs, 

•  Tests  which  did  not  meet  satisfactory  completion,  or  achieve  conditions 
defined  in  the  STD  under  which  the  test  result  is  inconclusive. 

•  Format  and  content  discrepancies. 

6.  Support  Reviews  and  Audits  by  : 

•  Providing  briefing  books  containing  summary  status  information  for  each 
critical  CSCI.  Summary  information  will  include  software  size  estimates, 
schedule  (planned  versus  actual),  and  action  items  to  be  addressed  during 
the  meeting, 

•  Participating  in  the  review  as  directed  by  the  Prime. 


Products 

Table  6.1. 2.3-2  defines  the  V&V  products  from  the  Post-CDR  Phase. 


Title 

Dcaicriptloii 

Format 

Guide 

Fre<jnency 

m 

TSd 

Once  per 
module 

TBD 

V&VPian 

TSd 

Once  per 
module 

Table  6. 1 .2.3-2  Post-CDR  Phase  Verification  Products 
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The  V&V  Plan  will  contain  the  following  results  from  the  Post-CDR  Phase: 

•  Requirements  which  are  not  addressed  by  design 

•  Software  and  Interface  design  features  which  do  not  support  a  higher-level 
requirement 

•  Format  and  content  discrepancies  based  on  the  contracts  specified  format 
contained  in  the  Software  Development  Han  for  items  in  the  Developmental 
Configuration 

•  Requirements  which  are  not  addressed  by  code 

•  Software  and  Interface  code  features  which  do  not  support  a  requirement,  or 
trace  directly  to  design 

•  Non-adherence  to  the  contractor's  software  standards  and  procedures 
format  and  content  requirements 

•  Requirements  for  which  no  test  is  identified 

•  Tests  identified,  but  for  which  a  requirement  that  cannot  be  identified 

•  Specifications  which  are  not  addressed 

•  Software  and  Interface  design  features  which  do  not  support  a  higher-level 
requirement 

•  Tests  identified,  but  for  which  a  requirement  cannot  be  identified 

•  Format  and  content  discrepancies 


6. 1.2.4  Code  and  Unit  Test 

The  following  documentation  should  be  provided  during  the  coding  and  unit  test 

phase: 


•  Test  results  which  do  not  support  the  objectives  of  the  STP  and  STDs 

•  Tests  which  did  not  meet  satisfactory  completion,  or  achieve  conditions 
defined  in  die  STD  under  which  Uie  test  result  is  inconclusive 

•  Identify  system/software  requirements  not  clearly  addressed  including 
recovery  fiom  failure  and  alternatives 

•  Requirements  for  which  no  test  is  reported 

•  Format  pnd  content  discrepancies 


6.1.3  Design  Walk-Throughs 

Die  ARWA  V&V  team  will  conduct  design  walk-throughs  in  each  functional  luoa  to 
check  that  the  design  will  fulfill  the  specified  requirements.  These  designs  will  be 
presented  by  the  functional  area  designers  and  will  dlow  the  V&V  team,  including  user 
community  personnel,  to  establish  that  the  designs  are  complete  and  balanced  and  meet  the 
requirements  of  the  user  community.  They  will  also  give  members  of  the  V&V  team  an 
opportunity  to  better  understand  the  designs  and  gain  insight  as  to  why  certain  design 
approaches  were  implemented. 

The  design  will  first  be  analyzed  to  see  that  it  incorporates  all  of  the  functionality 
specified  for  that  system.  If  all  specified  functionality  seems  to  have  been  incorporated, 
then  we  can  conclude  that  the  code  may  work.  If  anything  has  been  omitted  or  incorrectly 
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implemented,  then  we  can  conclude  that  the  code  will  not  work.  It  is  critical  that  all  logic 
statements  be  thoroughly  ctecked,  for.  if  errors  are  not  found  here,  snags  can  result  that,  if 
encountered  at  a  later  stage  of  development,  can  be  difficult  to  debug.  For  example,  a 
SHOOT  cue  may  only  be  obtained  if  the  weapon  is  selected  and  armed,  the  seeker  has 
locked  on.  the  weapon  is  in  range,  and  the  target  is  within  angular  constraints.  Thus,  the 
design  can  be  readily  checked  to  see  that  all  of  these  logic  statements  are  present 

The  designs  will  not  only  consider  each  functional  element  for  such  factors  as 
algorithms  and  logic,  but  also  for  the  relationship  between  them,  to  check  that  the  interfaces 
have  been  properly  defined.  The  areas  addre^^d  and  the  results  of  the  reviews  will  be 
documented — ^in  particular,  the  areas  where  deficiencies  are  found. 

The  specific  documents  to  be  reviewed  are  the  preliminary  and  final  Software 
Design  and  Interface  Design  Documents.  These  documents  will  be  compared  to  the 
allocated  baseline  to  assure  that  ail  requirements  have  been  addressed  and  that  no  software 
or  interface  design  requirement  exists  which  can  not  be  matched  to  a  corresponding  higher 
level  lequiremenL  Any  discrepancies  are  entered  into  the  discrepancy  and  problem  tracking 
data  base  maintained  by  the  CCB.  The  goal  of  reviewing  these  documents  is  to  assure  that 
all  requirements  have  b^n  addressed  and  that  no  software  or  interface  design  feature  exists 
which  can  not  be  matched  to  a  corresponding  requirement  Additional  data  may  be 
obtained  from  the  Software  Test  Plan  and  the  developers  contract  SOW. 


6.1.4  Flow  Diagram  Reviews 

The  ARWA  V&V  team  will  review  the  flow  charts,  top-down  structure  diagrams, 
data  flow  charts,  and  related  documentation  in  each  functional  area  in  conjunction  with  the 
design  walk-throughs.  Some  of  these  data  will  actually  be  used  in  tlie  design  walk¬ 
throughs  to  present  the  material,  while  other  data  will  be  reviewed  to  supplement  the 
information  gained  from  the  design  walk-throughs. 


6.1.5  Algorithm  Checks 

The  ARWA  V&V  team  will  evaluate  the  level  of  fidelity  of  all  key  equations  and 
algorithms  in  each  functional  area.  The  fidelity  and  mechanization  will  be  evaluated  against 
“accepted”  approaches  as  defined  i.n  reference  documentation  that  the  V&V  team  will 
assemble  in  the  library  development  task.  The  results  of  this  activity  will  be  documented  to 
note  which  equations  and  algorithms  were  reviewed  and  the  results  of  those  reviews.  The 
team  will  verify  that  the  level  of  fidelity  is  sufficiently  high  to  allow  air  crews  to  properly 
perform  their  R&D,  tactics  development,  and  evaluation  activities  in  the  ARWA  SS. 


6.1.6  Comparison  of  Pseudo-code  to  the  Design  Specifications 

After  the  pseudo-code  has  been  written  for  each  software  segment,  the  V&V  team 
will  compare  it  with  the  design  requirements  to  see  that  all  requirements  have  been 
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implenieiited.  This  is  a  critical  task  because  it  is  probable  ttat  the  peisoo«4io  created  the 
design  code  will  not  code  it  up.  The  ARWA  V&V  team  will  document  the  results  of  this 
review,  with  special  note  being  made  of  any  instances  where  elements  of  the  design  have 
not  been  imfdemented  or  have  been  implemented  improperiy. 


4.1.7  Logic  Representation 

The  purpose  of  this  activity  is  to  ptoducre  an  alternative  representatimi  of  the  logic  in 
the  design  and  compare  it  to  that  of  the  developer.  This  alternate  representation  should  be 
in  a  form  that  can  be  compared  to  that  of  the  developer.  A  different  method  of  generating 
the  logic  representation  than  that  used  by  the  developer  should  be  used.  The  primary 
purpose  of  this  alternative  refnesentation  is  to  independently  produce  a  logic  structure  that 
can  be  compared  to  that  of  the  developer.  This  technique  enables  the  verifier  to  identify  the 
required  logical  paths. 

The  ARWA  V&V  team  will  use  Computer  Aided  Software  Engineering  (CASE) 
tools  when  appropriate  to  assist  in  the  conversion  of  logical  process  descriptions  into 
computer  methods.  CASE  tools  may  also  be  used  by  the  developer  to  create  reports  and  to 
develop  tests  for  the  simulator  software  segment  from  the  computer-based  requirements 
and  design  data.  If  a  developer  uses  CASE  tools  then  the  V&V  team  will  adopt  consistent 
and  compatible  verification  methods. 

6.2  Code  VERIFICATION 

Once  the  logic  of  the  design  has  been  verified,  coding  can  begin.  The  following 
paragraphs  describe  the  activities  required  to  verify  the  coding  for  each  software  segment 
These  activities  can  be  performed  in  conjunction  with  code  development.  Indeed, 
performing  walk-throughs  and  peer  reviews  early  in  the  coding  phase  is  a  good  method  for 
enforcing  coding  standards,  as  well  as  establishing  points  of  contact  within  the 
development  organizations. 

The  Detailed  Software  and  Interface  Design  Documents  will  be  reviewed  during 
coding  and  unit  test  and  integration  to-sting  phases.  This  review  compares  the  SDD  and 
IDD  products  as  they  are  developed  and  controlled  by  the  segment  contractor,  against  the 
SRS  and  IRS  to  assure  that  no  software  or  interface  design  feature  exi.sts  that  can  not  be 
matched  to  a  corresponding  requirement  Source  code  will  l)e  compared  to  the  SRS, 
Detailed  Software  and  Interface  Design  Documents.  The  goal  as  before  is  to  assure  that  all 
requirements  have  been  addressed  and  that  no  software  or  interface  feature  is  implemented 
in  the  code  which  can  not  be  matched  to  a  corre^nding  requirement  SPARTA  will  also 
check  that  the  contractor  is  following  his  coding  standards  as  stated  in  the  developer's 
Software  Standards  and  Procedures  as  defmed  in  his  Software  Development  Plan. 

The  Software  Test  Descriptions  (STDs)  will  be  reviewed  prior  to  the  Test 
Readiness  Review  (TRR).  STDs  are  defined  prior  to  CDR  and  ate  further  refined  by 
defining  the  test  procedures  prior  to  TRR.  The  V&V  team  will  identify  the  specific  test 
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cases  and  detailed  procedures  which  will  provide  complete  and  objective  evidence  that  the 
unit  under  test  meets  its  requirements. 

The  Software  Test  Reports  are  compared  to  the  SRS  and  IRS  to  ensure  that  all 
planned  test  and  procedures  are  documented  with  results.  The  goal  of  this  review  is  to 
determine  that  all  test  were  exercised  or  explanations  are  present  and  that  the  results 
provided  sufficient  objective  evidence  that  the  unit  under  test  meets  its  requirements. 


6.2.1  Code  Walk-throughs 

After  the  code  has  been  written  for  each  software  segment,  the  V&V  team  will 
examine  the  code,  module  by  module,  to  ensure  efficiency,  correctness,  and  completeness 
of  implementation.  The  V&V  team  will  check  to  see  that  all  logic,  algorithms,  and 
equations  have  been  properly  implemented  and  that  the  interfaces  between  modules  have 
bran  properly  establi^ed. 

The  interfaces  with  other  modules  that  represent  other  elements  of  the  total 
simulation  will  be  closely  reviewed.  The  most  obvious  thing  to  look  for  is  that  all  required 
inputs  are  present  or  all  required  data  is  encapsulated  in  the  module.  For  example,  to  obtain 
a  lock-on,  a  seeker  may  require  that  its  missile  be  selected,  the  target  be  designated,  the 
laser  designation  code  match  that  of  the  weapon,  the  designated  point  be  within  the  seeker’s 
field  of  regard,  and  range  and  atmospheric  conditions  be  such  that  the  seeker  detects  the 
reflected  radiation.  Clearly,  if  any  of  the  inputs  associated  with  these  conditions  is 
missing,  the  model  will  not  work  correctly.  The  output  is  of  equal  importance,  since 
output  parameters  will  indicate  whether  or  not  the  specification  was  understood.  The 
output  in  this  case  is  simple — either  the  seeker  has  a  lock-on  or  it  does  not  (assuming  that 
posidoii  and  angulai'  data  defining  the  designated  point  comes  from  another  module). 

The  V&V  team  will  properly  document  these  walk-throughs,  with  particular  note 
being  made  of  any  deficiencies  found  or  any  changes  in  implementation  and  the  reason  for 
them. 


6.2.2  Peer  Review 

The  purpose  of  this  review,  which  is  conducted  by  independent  subject-matter 
experts,  is  to  analyze  modeling  assumptions  and  to  determine  their  implications.  This  may 
be  done  either  in  the  form  of  presentations  or  by  documentation  review.  The  outputs  of  the 
review  will  be  documented  and  fed  back  to  the  developers,  as  appropriate.  The  ARWA 
V&V  team  will  supplement  its  V&V  team  with  recognized  subject-matter  experts  to  perform 
this  task. 
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6.2.3  Units  Check 

The  ARW  A  V&V  team  will  perform  a  units  check  in  conjunction  with  design  and 
code  walk-throughs  to  ensure  that  units  have  been  prq)erly  defined  in  the  design  and  code 
implententations. 


6.2.4  Logic  Representation 

The  purpose  of  this  activity  is  to  produce  an  alternative  representation  of  the  logic  in 
the  code  and  compare  it  to  that  of  the  developer.  This  alternate  representation  should  be  in 
a  form  that  can  be  compared  to  that  of  the  developer.  A  different  method  of  generating  the 
logic  representation  should  be  used. 

The  ARWA  V&V  team  will  use  Computer  Aided  Software  Engineering  (CASE) 
tools  when  appropriate  to  assist  in  the  conversion  of  logical  process  descriptions  into 
computer  methods.  CASE  tools  may  also  be  used  by  the  developer  to  create  repoits  and  to 
develop  tests  for  the  simulator  software  segment  from  the  computer-based  requirements 
and  design  data.  If  a  developer  uses  CASE  tools  then  the  V&V  team  will  adopt  consistent 
and  compatible  verification  methods. 


6.2.5  Sensitivity  Analyses 

Sensitivity  analyses  basically  involve  testing  the  code  to  see  that  it  behaves  properly 
(the  models  are  sensitive  to  the  variables  of  interest)  at  the  module,  subsystem,  and  system 
levels.  The  V&V  team  will  develop  sets  of  nominal  and  boundary  condition  input  data  and 
will  perform  independent  calculations  (based  on  the  governing  logic  and  algorithms)  to 
determine  the  expected  results  for  each  software  element  for  each  set  of  initial  conditions. 
The  code  will  then  be  run  with  the  input  data  sets,  and  the  results  of  the  runs  will  be 
compared  with  results  obtained  from  the  independent  calculations. 

For  example,  in  evaluating  the  radar  model,  wc  will  check  for  proper 
implementation  of  the  radar  range  equation  and  the  impact  of  noise,  clutter,  and  jamming  to 
the  e.xtent  that  the  effects  of  these  factors  arc  to  be  modeled.  Since  detection  range  (output) 
is  a  strong  function  of  all  of  these  parameters  plus  the  radar  cross-section  of  the  target,  the 
radar  mode,  and  the  geometry  of  the  problem  (input),  the  system  will  have  to  be  evaluated 
under  many  conditions  in  order  to  verify  that  it  works  according  to  specification  and,  more 
importantly,  works  in  a  realistic  manner. 

The  V&V  team  should  expend  a  great  deal  of  effort  in  developing  as  many  data  sets 
as  possible  in  order  to  evaluate  as  many  sets  of  conditions  as  possible.  The  results  of  all 
testing  will  be  well  documented  and  deficiencies  noted,  as  will  the  results  of  follow-up 
testing  after  snags  have  been  worked  off. 
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0.2.6  Statistical  Tests  for  Stochastic  Models 

The  ARWA  V&V  team  will  design  statistical  tests  for  stochastic  models  when  the 
model  output  is  not  deterministic,  i.e.  output  is  not  repeatable  or  is  dependent  on  random 
processes  beyond  the  control  of  testers.  Subject  matter  experts  are  often  needed  to 
determine  if  results  are  "within  reason  or  expectation."  The  V&V  team  will  use  such 
experts  when  appropriate.  The  V&V  team  will  test  those  algorithms  which  contain  this 
type  of  processing  to  ensure  that  outputs  follow  the  intended  distributions. 

6.3  Specific  verification  Activities 

6.3.1  VSM 

SPARTA  will  verify  that  the  design,  logic,  and  code  of  the  Visual  System  Module 
(VSM)  will  provide  visual  and  sensor  image  generation,  moving  models,  lighting, 
environmental  scene  generation,  crew  station  interfaces,  and  out-the-window  displays  as 
specified.  The  Visual  System  Module  (VSM)  computer  image  generation  (CIG)  system  (an 
ESIG-20(X))  will  dedicate  one  of  its  channels  to  producing  the  FUR  image.  The  task  is  to 
verify  that  the  ESIG-2(X)0  properly  generates  IR  images  of  the  terrain  and  moving  models. 

SPARTA  does  not  have  any  means  of  generating  IR  imagery  from  the  terrain  and 
moving  model  data  bases.  We  could  use  FLIR90  to  generate  minimum  resolvable  contrast 
(MRC)  and  minimum  resolvable  temperature  differences  (MRTDs)  of  selected  targets  at 
selected  ranges,  at  selected  aspect  angles  against  selected  backgrounds  at  selected  times  of 
day  and  season.  We  would  then  have  to  extract  the  digital  image  from  the  ESIG-2000 
under  the  same  selected  conditions  (I  don't  know  if  that's  possible).  The  extracted  image 
could  then  be  analyzed  to  determine  if  the  ESIG'2000  correctly  uansformed  the  terrain  and 
tnoving  model  3D  iiepre.scntation.s  into  2D  IR  image.s. 

Table  6.3.1  shows  the  logic  and  code  verification  activities  that  are  to  be  performed 
during  each  development  pha.se  for  this  component 
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Phase: 

Activitv: 

PrePDR 

TDR-CBR 

Post-Ct>R 

Logic  verification 

ttocumentatiQn  Review 

V 

Design  Wa^-throu|th 

Flow  diagram  Review 

V 

AlgtHithm  Checks 

Logic  kepiesentation 

V 

Code  Verification 

Code  Walk-through 

V 

Peer  Review 

V 

Units  Check 

V 

Logic  kepiesentation 

V 

Sensitivity  Analysis 

V 

^tatisdcalTest 

Table  6.3. 1  Logic  and  Code  Verification  Activities  for  the  VSM 

6.3.2  FSM 

6. 3. 2.1  FSM  Base 

Table  6.3.2. 1  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 


Pre-PDR 

ymujn 

mnn 

MKflHH 

V 

V 

■H  a  [ti'Jl  K  n  t:'f  1 1  ■ 

UBIB 

M  l!  r~\i  ii  — 

Logic  Representation 

V 

Code  Verification 

V 

V 

V 

\f 

■■■■■■ 

Table  6.3.2. 1  Logic  and  Code  Verification  Activities  for  the  FSM  Base 


-43- 


ADST/TR  94-003282 


April  15,  1994 


6. 3. 2. 2  FSM  Comanche 
Cockpit 

Base  control  loading 
collective 
cyclic 

foot  pedals  (toe  brakes  only) 

Coclqnt  pilot  instrument  panel 
Cockpit  co-pilot/gunner  instrument  panel 

Table  6.3.2.2  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  develoinnent  phase  for  this  component 


Phase: 

Activity: 

hlllil  IlM 

1  Documentation  Review 

V 

yl 

V 

HH  i  ^  (TTtrm  iVHi 

V 

— a  ^  HA'i  'AM 

yl 

V 

■r.rrirm’rr:f(rrnrT^* 

yi 

V 

—mriMi  itti'tit— 

■vf 

yi 

1  Statistical  Test 

Table  6.3.2.2  Logic  and  Code  Verification  Activities  for  the  FSM  Comanche 


6. 3. 2. 3  FSM  Longbow 
Cockpit 

Base  control  loading 
collective 
cyclic 
foot  pedals 

Cockpit  pilot  instrument  panel 

Cocl^it  co-pilot/gunner  instrument  panel 
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Table  6.3.2.3  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 


Documentation  Review 

V 

V 

V 

■■  1  rroTtprMi 

V 

MMiin  li'i 

V 

HIKl  I'ii! ,  11  ii  t  iltl  irjy 

V 

— j  t!  V  j 

■■■■■ 

V 

I  rriTTij  ITnQ 

V 

V 

I  Statistical  Test 

Table  6.3.2.3  Logic  and  Code  Verificadon  Acdvities  for  the  FSM  Longbow 


6.3.3  SSM 

6.3.3. 1  RAH-66  Comanche  Kit 

6.3.3. 1 . 1  Ry\H-66  Right  Controls 

The  following  are  the  requirements  for  the  Flight  Controls  from  the 
System/Segment  Spccificadon: 

"The  flight  controls  segment  shall  simulate  the  flight  controls  for  the  RAH-66 
aircraft  Simulations  shall  include  primary  controls,  trim,  hinge  moments,  automadc  flight 
controls  systems  (AFCS),  miscellaneous  control  devices,  and  toe  brakes/anti-skid.  The 
flight  controls  simulation  shall  also  include  the  ability  to  set  and/or  adjust  certain  device 
parameters  including  maximum  pitch,  roll  and  yaw  rates:  turning  radius;  flight  controls 
input  sensitivity;  number  of  blades;  no  tail  rotor  effect  on  performance;  and  stochastic 
failurcs  from  combat  and  crash  damage  tables." 

"The  surface  positions  shall  be  determined  from  the  cockpit  control  device  inputs 
(cyclic  stick,  collective  stick  and  directional  pedals),  AFCS  inputs,  hydraulic  pressures, 
electrical  power,  and  malfunction  (battle  damage)  data.  The  primary  controls  function  shall 
include  the  simulation  of  surfaces  or  controls  such  as  actuators,  swashplates  and  blade 
pitch  (main  and  tail).  The  control  loading  system  shall  drive  the  primary  control  input 
devices  (cyclic  stick,  collective  stick  and  directional  pedals)  to  provide  the  proper  control 
feel  for  the  pilot.  This  includes  the  effects  of  cyclic  uim  or  force  trim.  In  the  case  of  the 
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RAH-66,  only  the  collective  stick  and  the  brake  pedals  shall  requite  force  loading  on  the 
controls.  This  shall  include  simulation  of  tl^  artificial  feel  system  and  friction,  spring 
forces,  deadband,  inertia  and  hysteresis  appropriate  to  each  control  input  device.  The 
force  servo  closed-loop  response  shall  be  stable  and  rapid  enough  to  provide  realistic 
dynamic  feel.  The  control  loading  system  shall  have  dynamic  responses  which  are 
sufficiently  realistic  to  prevent  distraction  of  the  pilot  and  to  ensure  that  the  pilot  remains 
combat  effective." 

"The  "cyclic  trim"  or  "trim  feel"  function  shall  be  modeled  for  the  baseline  air 
vehicles  with  the  exception  of  the  RAH-66.  This  shall  include  the  force  acting  on  the  cyclic 
stick  and  directional  control  pedals  to  center  and  provide  an  artificial  feel  of  being  in  a  trim 
state." 


"A  simulation  of  hinge  moments  acting  on  the  aerodynamic  control  surfaces  of  the 
baseline  aircraft  shall  be  provided,  if  necessary,  and  shall  restrict  movement  of  those 
aerodynamic  surfaces  appropriately." 

"The  AFCS  simulation  shall  provide  the  capabilities  of  heading  hold,  pitch  hold, 
roll  hold,  attitude  hold,  hover  hold,  and  velocity  stabilization  as  required  for  each  air 
vehicle  configuration  according  to  Figure  3. 1.1. 1.1. 4-1.  Stability  augmentation 
simulations  shall  provide  improved  stability  in  the  pitch,  roll  and  yaw  axes  by  providing 
aircraft  damping.  The  stability  augmentation  system  shall  oppose  any  deviation  in  attitude, 
but  shall  not  return  the  aircraft  to  a  given  attitude  or  heading.  The  simulation  shall  provide 
for  stability  augmentation  to  be  engaged  at  all  times  in  pitch,  roll  and  yaw  mode.  Sensed 
rate  signals  and  Central  Air  Data  Computer  (CADC)  inputs  shall  be  used  in  determining 
pitching,  rolling,  or  yawing  motion." 

"Miscellaneous  controls  including  stabilator  position,  landing  gear  positions, 
weapon  bay  door  positions,  and  tail  wheel  locked  status  shall  be  simulated.  The 
normalized  positions  and  states  (e.g.,  open,  opening,  closed,  etc.)  of  the  miscellaneous 
control  devices  shall  also  be  determined." 

"The  simulation  of  braking  effects  shall  be  modeled  for  the  RAH-66  aircraft.  The 
RAH-66  simulation  shall  use  brake  pedals  mounted  on  foot  tests.  The  effects  required  to 
be  supplied  during  braking  operation  shall  include  brakes  on  and  off." 

RAH-66 

Simulate  primary  controls  determined  by  cyclic  and  collective  controls: 

-  main  rotor  actuators  and  surface  positions 

-  fantail  actuators  and  surface  positions 

Simulate  automatic  flight  controls  system  (AFCS)  by  modeling  AFCS  control  laws 
to  provide: 

-  stability  augmentation 

-  trim  hold 

-  selectable  capabilities  from  Table  6.3.3.1.1-1  below: 
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Pitch 

Roll 

Hold 

Yaw 

Hold 

Attitude 

Hold 

Hover 

Hold 

Velocity 

Y 

Y 

Y 

Y 

Y 

Y 

Table  6.3.3.1.1-1  RAH-66  Flight  Controls  Selectable  Capal^ties 


Simulate  FHyht  Director 

Simulate  flight  director  to  provide  steering  commands  to  the  pilot  and  to  the  AFCS 
to  obtain  fire  control  solutions  when  operating  in  the  Integrated  Fire/Flight  Control  mode, 
or  to  provide  steering  commands  to  the  pilot  and  AFCS  to  obtain  navigation  waypoint 
steering  when  in  the  Coupled  Navigation  mode. 

Check  the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  segment 
will  perform  as  specified: 

-  primary  controls  simulation  of: 

-  control  laws 

-  main  rotor  and  fantail  actuators  and  surface  positions  determined  from  the 

cockpit  control  devices  (cyclic  and  collective  controls) 

-  trim  inputs 

•  aircraft  state  information 

-  AFCS  inputs 

-  hydraulic  pressures 

-  electrical  power 

-  battle  damage 

-  cyclic  inputs  (longitudinal,  lateral,  directional  slick  coniinands)  and  the 

collective  stick  command  provided  by  the  Digital  Control  Loading 
(DCL)  hardware 

-  limited  vertical  stick  command  provided  by  the  DCL 

-  DCL  simulation  of  the  force  feel  characteristics  of  the  left  hand  collective, 

provision  of  analog  voltage  for  the  right  hand  sidearm  controller 
(cyclic),  and  backdrive  of  the  collective 

-  automatic  flight  controls  system: 

-  simulation  of  the  AFCS  control  laws  to  provide  stability  augmentation, 

trim  hold  and  selectable  capabilities 

-  interface  with  the  fliglit  direaor  function  to  provide  coupled  navigation  and 

integrated  fue  control 

-  flight  director  simulation  of  the  ability  of  the  RAH-66  aircraft  to  perform 

integrated  fire/flight  control  and  coupled  navigation 

-  miscellaneous  control  devices  simulation  of  the  extension/retraction  of  the  landing 

gear  and  opening/closing  of  the  landing  gear  doors 

-  ability  to  set  and/or  adjust  the  flight  controls  segment  adaptability  parameters 

-  degradation  of  flight  controls  operation  due  to  battle  damage  based  on  severity  and 

location  of  damage 
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Table  6.3.3.1.1-2  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  develofHnent  phase  for  this  component 


V 

V 

V 

V 

V 

V 

V 

l;i  1  "'ll  1  III  1  1  ■■ 

V 

■•pr.  rm7T!f  ifTTirr™* 

>/ 

V 

v 

1  Statistical  Test 

Table  6.3.3. 1 . 1  -2  Logic  and  Code  Verification  Activities  for  RAH-66  Flight  Controls 


6.3.3. 1.2  RAH-66  Nav/Coram 
HARS/AHRS 

The  same  approach  used  for  the  AH-64D  will  be  used  for  the  RAH-66. 

Provides  helicopter  attitude  outputs  for  pitch,  roll,  heading,  velocities,  and 
accelerations  as  required  by  other  ownship  systems. 

DNS 

Tlje  .same  approach  used  for  the  AH-64D  will  be  u.s<xl  for  the  RAH-66. 

From  the  Syslem/Segment  Specification:  "Radio  Navigation  Aid  System.  Tne 
ASN-137  Doppler  Navigation  System  (DNS)  will  be  controlled  through  the  Computer 
Display  Unit  (CDU)  IP-1.552/G.  Simulation  of  DNS  accuracy  degradation  due  to  altitude 
and  high  pitch  and  roll  angles  is  not  required.  The  Navigation  mode  of  the  ASN-137 
model  shall  be  functional.  Modes  such  as  backup.  Hover  Bias  Calibration,  and  Test  modes 
are  not  required.  All  CDU  (or  MFD)  pages  shall  be  accessible  through  the  proper  use  of 
key  selections  and  data  entry  and  the  display  shall  be  simulated.  Navigation  data  required 
to  provide  steering  commands  shall  be  dependent  upon  pilot  data  entry.  Simulation  of  the 
Fault  Detection/Location  System  (FD/LS)  function  is  not  required." 

GPS 

The  same  approach  used  for  the  AH-64D  will  be  used  for  the  RAH-66. 

"A  generic  Global  Positioning  System  (GPS)  shall  be  modeled  to  provide  accurate 
position  and  velocity  information  for  use  by  other  systems." 
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"This  information  will  be  derived  from  the  equations  of  motion  in  the  Flight 
Dynamics  segment,  then  modified  to  account  for  electiical  system  ^tus,  battle  damage, 
and  adaptability  parameters." 

ICS  (InlereommunicatipDS  Sysiem) 

Cl  1746/ARC 

VHFCOMMS  (FM  and  AM) 

ARC-186 

UHFCOMMS 

ARC-164 

Voice  communications  capabilities  of  the  above  subsystems  are  summed  into  one 
segment  to  provide  the  required  communication  capabilities.  The  foUowing  was  taken  from 
the  System/^gment  Specification  and  describes  die  required  communications  functionality. 

"Voice  reception  from  crewmembers  and  other  vehicles  shall  be  possible  at  all  times 
as  long  as  the  receiver  select  switches  on  tlie  ICS  panel  are  on,  the  volume  is  turned  up, 
and  LOS  is  possible.  The  simulation  shall  provide  for  mmiitoring  of  up  to  five  radios.  The 
transmit  selector  switch  shall  be  active  in  tte  RMT  position  only,  allowing  the  pilot  to  select 
the  desired  radio  to  transmit  on  from  the  remote  transmitter  sel^t  switch  on  the  cyclic  stick. 
The  Hot  Mk  and  Mic  switches  fimctions  are  not  required.  Nav  audio  (Automatic  Direction 
Finder  (ADF)  or  Identification  Friend  or  Foe  (IFF))  monitoring  are  not  required.  A 
communication  link  shall  be  provided  to  provide  voice  reception  and  transmission  to  the 
Commander's  workstation  in  the  TOC." 

"The  pilot  and  CPG  ARC- 186  VHF  radios  shall  be  functional  in  AM  and  FM 
modes.  D/F  mode  simulation  is  not  required.  Frequency  selection  shall  be  functional  in 
the  manual  and  preset  modes  but  not  in  emergency  mode.  Squelch  control  or  tone  select 
functions  are  not  required.  Insertion  of  static  and  noise  due  to  equipment  interference, 
atmospheric  conditions,  or  range  is  not  required.  The  ability  to  receive  communications 
shall  be  dependent  on  line  of  sight  and  proper  operation  of  the  VHF  control  panel  and  ICS 
panel  selections.  VHF  communications  volume  shall  not  be  controlled  from  the  ARC- 186 
panel." 

"The  pilot's  ARC- 164  UHF  radio  shall  be  fully  functional,  including  the  guard 
receiver.  Squelch  control,  and  tone  .select  functions  do  not  require  simulation.  The 
HAVEQUICK  function  does  not  require  simulation.  Insertion  of  static  and  noise  due  to 
equipment  interference,  atmospheric  conditions,  or  range  is  not  required.  The  ability  to 
receive  communications  shall  be  dependent  on  line  of  sight  and  proper  operation  of  the 
VHF  control  panel  and  ICS  panel  selections." 


AIKDAIA 

ADSS  (Air  Data  Sensor  System) 

Provide  the  following  information  to  the  other  ownship  systems: 

-  calibrated  and  indicated  ait:^)eed 

-  temperature,  static  pressure,  and  all  air  mass  data 
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>  height  above  ii»an  sea  level 

The  above  data  is  modified  based  on  power  status,  battle  damage,  and  on/off 
adaptability  parameter. 

ATHS 

(Airborne  Target  Handover  System) 

"The  ATHS  shall  be  simulated  and  shall  interface  properly  through  the 
Communications  system.  ATHS  communications  shall  be  possible  between  all 
appropriately  equipp^  aircraft  and  the  Ccxnmander's  workstation  in  the  Tactical  Operations 
Center  (TOC)." 

MOVING  MAP 

"The  RAH-66  moving  m^  system  and  all  associated  controls  shall  be  simulated. 
The  map  control,  map  navigation,  mtq)  tactical,  and  map  scale  function  shall  be  simulated. 
Overlay  options  as  required  by  these  functions  shall  be  simulated.  Aircraft  position  data 
provided  to  the  m^q)  system  will  be  obtained  from  the  q>propriate  navigational  source." 

Table  6.3.3. 1.2  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component. 


Phase: 

Activity: 

1  Documentation  Review 

V 

V 

V 

MM  1  iTTTrm 

V 

V 

^i|i  1 IM 

V 

V 

V 

M*nT!  i  fTTJ  riTMMBi 

V 

1  Peer  Review 

V 

yl 

V 

V 

■■■■■■ 

■■■■■ 

V 

Table  6.3.3. 1 .2  lx)gic  and  Code  Verification  Activities  for  RAH-66  Nav/Coram 


6.3.3. 1.3  RAH-66  Weapons 

The  following  assumptions  were  made  by  Boeing  for  the  Comanche  weapons.  If 
requirements  exist,  validation  of  multiple  Hellfire  systems  will  be  performed  for  the 
Comanche.  See  Boeing's  section  of  the  PMR  No.  2  briefing.  Similar  assumptions  will  be 
made  for  the  Longbow  weapons: 

-  no  simulated  gun  barrel  wear 
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-thnist  misalignment  due  to  down  wish  only 
•  yaw  and  projectile  drift  not  simulated 

-  pmt’Starboaid  eirors  not  simulated 

-  perfect  gunsights 

-  no  vil»ration  enois 

The  System  /  Segment  Specification  feu:  the  RAH  66  states  tte  aircraft  has  two  gun 
systems  but  the  aircraft  should  only  have  (me  gun  onboard  and  available  for  use.  We  have 
therefore  defined  two  gun  system  options  in  describing  the  verification  and  validation 
efforts  on  the  weapons  systems. 

Check  the  design,  logic  and  code  in  the' computation  of  ownship  combat  damage. 
Determine  that  the  probabilities  of  kill  and  damage  are  properly  computed  as  a  function  of 
the  weapon  (warhead)  and  its  detonation  location  relative  to  predefined  aircraft  zones. 

VULCAN  II,2Qmm  Gun 

Represent  trajectory  of  ballistic  projectile  using  a  flyout  table.  Aerodynamic 
modeling  not  required.  Generate  dispersion  pattern  of  multiple  rounds  centered  on  a 
simulated  single  projectile. 

Compare  flyout  and  dispersion  patterns  logic  to  the  logic  implemented  in  the  model 
INCURSION  embedded  in  ALWSIM. 

Check  the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  system 
will  perform  as  speciHed: 

.  bullets  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  gun  can  be  selected  and  armed  (master  arm) 

-  gun  correctly  positicHied  ( AUTQiOX)SED/LOAD/DEFLOY) 

-  gun  can  be  targeted  within  correct  azimuth  and  elevation  limits 
.  gun  can  be  fired  -  trigger  1st  and  2nd  detent  operation 

-  rounds  remaining  decreases  properly 

-  bullets  follow  proper  trajecu^  and  impact  about  targeted  point 

-  compute  all  data  required  by  Environment  segment  for  DIS  PDUs 
NEEDED:  VULCAN  n  20ium  Gun  capabilities  description 

2.75"I?FARMK:66 

Represent  trajectory  of  each  powered  projectile  using  a  flyout  table.  Aerodynamic 
modeling  not  required.  Generate  dispersion  pattern  centered  on  projectile  trajectory. 

Compare  flyout  and  dispersion  patterns  logic  to  the  logic  implemented  in  the  model 
INDIRECT  FIRE  EFFECTS  embedded  in  ALWSIM. 

Check  the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  system 
will  perform  as  specified: 

-  rockets  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  rockets  can  be  selected  and  armed  (master  arm) 

-  rockets  can  be  properly  targeted 

-  rockets  can  be  fired  -  trigger  1st  and  2nd  detent  operation 

-  number  remaining  decreases  properly 

-  rockets  follow  proper  trajectory  and  impact  about  targeted  point 
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-  compute  all  data  required  by  Environment  segment  for  IHS  PDUs 
NEEDED:  175"  FFARMK-66  capabilities  description 

HYDRA  70 

Represent  trajectory  of  each  powered  projectile  using  a  flyout  table.  Aerodynamic 
modeling  not  required.  Generate  dispersion  pattern  centered  tm  projectile  trajectory. 

Compare  flyout  and  division  patteros  logic  to  the  logic  implemented  in  the  model 
INDIRECT  FIRE  EFFECTS  embedded  in  ALWSIM. 

Check  the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  system 
will  perform  as  specified: 

-  rockets  can  be  loaded  and  the  number  of  rounds  is  properly  di^layed 

-  rockets  can  be  selected  and  armed  (master  arm) 

-  rockets  can  be  properly  targeted 

-  rockets  can  be  fired  -  trigger  1st  and  2nd  detent  operation 

-  number  remaining  decreases  properly 

-  rockets  follow  proper  trajectmy  and  impact  about  targeted  point 

-  compute  all  data  required  by  Environment  segment  for  DIS  PDUs 
NEEDED:  IflfDRA  70  capabilities  description 

AGM-114A  LASER  HFI.1.FIRF 

Represent  trajectory  of  each  powered  missile  using  a  flyout  table.  Aerodynamic 
modeling  not  required.  Model  acquisition  probability  as  a  function  of 

-  range  to  target 

-  laser  range  to  target 

-  reflected  energy 
•  background 

Use  PHI  model  in  ALWSIM  for  laser  target  acquisition  probability  comparison. 

Use  ALWSIM  flyout  logic  for  comparison  to  HELLFIRE  flyout. 

Check  the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  system 
will  perform  as  specified: 

-  missiles  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  missiles  can  be  selected  in  desired  sequence  and  aimed  (master  arm) 

-  missiles  can  be  properly  targeted  to  obtain  "SHOOT’  cue 

•  target  within  kinematic  range  of  misale 

-  target  must  be  designated  with  correct  code 

-  target  can  be  designated  autonomously  or  remotely 

-  seeker  must  acquire  (function  of  range/weather,  CLOS) 

-  designated  target  within  seeker  azimuth  and  elevation  FOV  limits 

-  aircraft  launch  constraints  must  be  met 

-  indirect  fire  and  lock-on-after-launch  modes 

-  missiles  can  be  fired  -  trigger  1st  and  2nd  detent  operation 

-  missiles  fire  in  selected  order 

-  number  remaining,  and  their  location,  properly  displayed 

-  missiles  follow  proper  trajectory  and  impact  target 

-  compute  all  data  required  by  Environment  segment  for  DIS  PDUs 
NEEDED:  AGM- 1 14A  LASER  HELLFIRE  capabilities  description 
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Air  To  Air  Stinger  (AIAS) 

Represent  trajectory  of  each  powered  missile  using  a  flyout  tabte.  Aerodynamic 
modeling  not  required.  Model  acquisition  probability  as  a  function  of  range  to  target, 
minimum  resolvable  contrast  (MRC),  and  minimum  resolvable  temperature  differences 
(MRTDs).  Model  kill  probability  using  above  information. 

Use  FUR90  model  in  ALWSIM  for  IR  target  acquisition,  tracking,  and  end-game 
probability  comparison. 

Use  ALWSIM  flyout  logic  for  comparison  to  ATAS  flyout 

Check  the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  system 
will  perform  as  specified: 

-  missiles  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  missiles  can  be  selected  in  desired  sequence  and  armed  (master  arm) 

-  missiles  can  be  properly  targeted  to  obtain  "SHOOT"  cue 

-  seeker  must  acquire  (functitm  of  range/weather,  CLOS,  target  IR  intensity) 

-  seeker  slaves  to  targeting  system 

-  designated  target  within  se^^  azimuth  and  elevation  FOV  limits 

-  seeker  provides  cue  for  tone 

-  missiles  can  be  fired  -  trigger  1st  and  2nd  detent  operation 

-  missiles  fire  in  selected  order 

-  number  remaining,  and  their  location,  properly  displayed 

-  missiles  follow  proper  trajectory  and  impact  target 

-  compute  all  data  requited  by  Environment  segment  for  DIS  PDUs 
NEEDED:  Air  To  Air  Stinger  capabilities  description 

Table  6.3.3. 1.3  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 


Pre-i>Dfe 

PDR-CDR 

Post-CDR 

IfTiilil'l  ITh  — 

Dncumcntntion  Review 

N 

V 

yj 

Design  Walk-through 

V 

'i 

a  rr”i  ^trrnrri  rTTirar* 

V 

V 

■rstmraRymin'TTrr-— 

V 

1  Peer  Review 

V 

V 

V 

Sensitivity  Analysis 

yj 

StatisficalTest 

Table  6.3.3. 1 .3  Logic  and  Code  Verification  Activities  for  RAH-66  Weapons 
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6.3.3.1.4  RAH-66  Sensors 

NVPS  (Based  on  the  AN/AA(J-1 '  FUR  PNVS) 

The  Visual  System  Module  (VSM)  computer  image  generation  (CIG)  system  (an 
ESIG-2(XX))  will  dedicate  one  of  its  channels  to  producing  the  FUR  image.  The  task  is  to 
validate  that  the  ESIG-2(X)0  properly  generates  IR  images  of  the  terrain  and  moving 
models. 

SPARTA  does  not  have  any  means  of  generating  IR  imagery  from  the  terrain  and 
moving  model  data  bases.  We  could  use  FUR90  to  generate  minimum  resolvable  contrast 
(MRC)  and  minimum  resolvable  temperature  differences  (MRTDs)  of  selected  targets  at 
selected  ranges,  at  selected  aspect  angles  against  selected  backgrounds  at  selected  times  of 
day  and  season.  We  would  then  have  to  extract  the  digital  image  from  the  ESIG-2(XX) 
under  the  same  selected  conditions  (I  don't  know  if  that's  possible).  The  extracted  image 
could  then  be  analyzed  to  determine  if  the  ESIG-20(X)  correctly  transformed  the  terrain  and 
moving  model  3D  representations  into  2D  IR  images. 

EOTADSforTAS) 

The  following  assumptions  were  made  by  Boeing  for  the  Comanche  EOTADS. 
See  Boeing's  section  of  the  PMR  No.  2  briefing.  I  am  assuming  that  similar  assumptions 
will  be  made  for  the  Longbow  AN/AA(}-170  TADS. 

-  target  detection  and  classification  shall  be  probabilistically  determined  as  a 

function  of  range  to  target,  visibility,  and  adaptability  parameters 
(see  Faxed  material) 

"  frequency 
--etc. 

•  target  prioritization  shall  be  a  function  of  sensor  ID,  target  type,  and  range 

-  laser  range  error  will  be  a  function  of  the  adaptability  parameter 

Table  6.3.3. 1.4  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 
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i^hase: 

Activitv: 

Rre-PDR 

■PBR-CftK" 

“PSiTCDir 

CUT 

Logic  Verifleation 

Docimientatioa  Review 

V 

V 

Tiestp  WallE-t&bu^ 

>/ 

V 

Flow  Diagram  Review 

V 

Algmithm  C^hecks 

V 

Logic  Representation 

V 

Code  Verification 

Code  Walk-through 

V 

Peer  Review 

V 

Umts  Check 

V 

Logic  Representation 

V 

Sensitivity  Analysis 

yi 

Statistical  Test 

V 

Table  6.3.3. 1 .4  Logic  and  Code  Verification  Activities  for  RAH-66  Sensors 


6.3.3. 1.5  RAH-66  ASE 
Radar  Warning  APR.39  (V)l  (V)2 

Simulate  RF  emitter  detection  and  identification  performed  by  the  Radar  Warning 
Receiver  (RWR). 

Provide  receiver  status,  RF  indications,  and  alerts  to  the  FSM. 

RF  indications  include  detection  range  and  parameter  limit  detection 
(frequency,  PRF,  and  PW). 

The  intent  is  to  characterize  the  performance  of  the  RWR  by  defining  the  following 
adtqitability  parameters: 

-  frequency 

-  PRF  (pulse  rcpcdtinri  frcqiKncy) 

-  PW  (pulse  width) 

-FOV  (field  of  FOV) 

-  detection  range 

-  direction  finding 

Check  the  design,  code  and  logic  to  verify  that  the  following  parameters  will  be 
properly  computed  in  accordance  with  the  radar  warning  adaptability  parameters;  EID  file; 
threat  emitter  type,  location,  power,  mode,  and  beam  characteristics;  and  ownship  location 
and  orientation; 

-  equipment  functional  status  from  electric  power  indications  and  sustained  battle 

damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  resui'  f  sustained  battle 

damage  in  the  areas  of  the  equipment  and/or  sensor-- 

-  identification  in  accordance  with  file  and  emitter  beam  parameter 
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-  maxim'Jin  detection  range  and  range  estimate  from  ED.  EID  file  and  detected 

power 

-  detection/no  detection  from  maximum  range  and  threat  and  ownship  locatitms 

-  coarse  radar  site  list  for  radar  warning  receiver  and  radar  jammer  operation 

-  emitter  mode  (search,  acquisition,  track,  (x*  missile  activity)  from  EED  file  and 

emitter  beam  characteristics  and  activity 

-  emitter  relative  bearing  from  AOA  information  and  ownship  heading 

-  emitter  priority  based  on  priority  in  EID  file,  detecting  equipment  and  range 

-  emitter  location  based  on  range  and  bearing 

-  emitter  location  based  on  triangulation  processing  by  multiple  team  members 

-  radar  warning  indications  (up  to  8  visual  effects  and  up  to  S  visual  effects), 

prioritized  target  list  and  other  interface  parameters  computed  and  passed 

-  detection  characteristics  can  be  modified  within  the  limits  of  tte  radar  warning 

adaptability  parameters 

NEEDED:  APR-39  (V)l  (V)2  ciq)abilities  (tescription. 

Radar  Jammer  AL(>136(V)l/5 

Simulate  the  matching  of  detected  RF  emitter  to  jamming  signal. 

Identify  detection  range  and  parameter  limits. 

Provide  radar  jammer  status  to  the  FSM. 

Provide  the  interface  to  the  DIS  network  protocols  for  the  transmitted  RF  signal(s). 
The  intent  is  to  characterize  the  performance  of  the  jammer  by  defining  the 
following  adaptability  parameters: 

-  frequency 

-  power 

-  technique 

-FOV  (field  of  FOV) 

-jam  range 

Check  the  design,  code  and  logic  to  verify  that  the  following  parameters  will  be 
properly  computed  in  accordance  with  the  radar  jammer  adaptability  parameters;  EID  file; 
course  radar  site  list;  and  ownship  location  and  orientation: 

-  equipment  functional  status  from  electric  power  indications,  ECM  enable  status 

and  sustained  batUe  damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  the  areas  of  the  equipment  and/or  antennas 

-  emitter  detected  if  on  course  radar  site  list  generated  by  radar  warning  receiver 

-  emitter  prioritized  in  accordance  with  EID  file  and  range  between  emittei  site 

location  and  ownship  location 

-  AOA  evaluations  using  ownship  angular  position  values,  actual  earth  axis  azimuth 

and  elevation  to  the  emitter,  and  EID  file  error  indications 

-  radar  jamming  parameters  using  results  of  the  AOA  evaluations,  the  RF  emitter's 

beam  parameters  and  the  EID  file  januning  indications 

-  RF  jamming  characteristics  required  to  effectively  simulate  the  jamming  of  the 

selected  emitters  (up  to  10)  and  other  interface  parameters  computed 
and  passed 
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’jamming  characteristics  can  be  modified  within  the  fimits  of  the  radtf 
adaptability  parameters 

NEEDED:  ALQ’136  (V)l/S  capabilities  description. 

User  Warning  avr*2(V)tbd 

Simulate  laser  emitter  detection  and  identification  performed  by  the  Laser  Warning 
Receiver  (LWR). 

Provide  receiver  status,  laser  indications,  and  alerts  to  the  FSM. 

The  intent  is  to  characterize  the  performance  of  the  LWR  by  defining  the  following 
adaptability  parameters: 

-frequency 

-  PRF  (pulse  repetition  frequency) 

-  PW  (pulse  width) 

-FOV  (field  of  FOV) 

-  detection  range 

Check  the  design,  code  and  logic  to  verify  that  the  following  parameters  will  be 
properly  computed  in  accordance  with  the  laser  warning  adaptability  parameters;  laser  ID 
file;  laser  type,  location,  power,  code,  and  beam  characteristics;  and  ownship  location  and 
orientation: 

-  equipment  functional  status  from  electric  power  indications  and  sustained  battle 

damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  the  areas  of  the  equipment  and/or  sensors 

-  identification  in  accordance  with  la^  ID  file  and  laser  beam  parameters 

-  maximum  detection  range  and  range  estimate  frran  ID,  laser  K)  file  and  detected 

power 

-  deteclion/no  detection  from  maximum  range  and  laser  and  ownship  locations 

-  laser  code  fiom  laser  ID  file  and  laser  beam  characteristics 

-  laser  relative  bearing  from  AOA  information  and  ownship  heading 

-  laser  priority  based  on  priority  in  laser  ID  file  and  range 

-  emitter  location  based  on  range  and  bearing 

-  emitter  location  based  on  triangulation  processing  by  multiple  team  members 

-  laser  warning  indications  (up  to  TBD  visual  effects  and  up  to  TBD  visual  effects), 

prioritiTed  target  list  and  other  interface  parameters  computed  and  passed 

-  detection  characteristics  can  be  modified  within  the  limits  of  the  IR  warning 

adtq)tability  parameters 

NEEDED;  AVR-2  (V)  capabilities  description. 

IR  Jammer  AL(i-i44(V)i/3 

Simulate  IR  jamming  characteristics:  power,  fiequency,  field  of  view. 

Provide  IR  jammer  status  to  the  FSM. 

Provide  the  interface  to  the  DIS  network  protocols. 

The  intent  is  to  characterize  the  performance  of  the  IR  jammer  by  defining  the 
following  adaptability  parameters: 

-  frequency 
-power 
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-technique 

Check  the  design,  code  and  logic  to  verify  that  the  following  parameters  will  be 
properly  computed  in  accordance  with  the  IR  jammer  adaptability  parameters;  IR  jammer 
charact^tics;  location  of  IR  seeker;  and  own^p  location: 

-  equipment  functional  status  from  electric  power  indications,  ECM  enable  status 

and  sustained  battle  damage 

-  reduced  c^bility  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

dam^  in  the  areas  of  the  equipment  and/or  IR  element 

-  IR  jamming  parameters  for  simulation  of  the  cooldown  and  warmup  cycling 

technique 

-  IR  jamming  characteristics  and  other  interface  parameters  computed  and  passed 

-  jamming  characteristics  can  be  modified  within  the  limits  of  the  IR  jammer 

adaptability  parameters 

NEEDED:  ALQ-144  (V)l/3  capabilities  description. 

Radiation  Warning  System  (RWS) 

Simulate  radiation  detection  and  identification  performed  by  the  Radiation  Warning 
System  (RWS). 

Provide  detector  status,  radiation  indications,  and  alerts  to  the  FSM. 

The  intent  is  to  characterize  the  performance  of  the  RWS  by  defining  the  following 
adaptability  parameters: 

-  sensitivity  of  detectors 

-  detector  pattern 

-  detection  azimuth 

Check  the  design,  code  and  logic  to  verify  that  the  following  parameters  will  be 
properly  computed  in  accordance  with  the  radiation  warning  adaptability  parameters; 
radiological  ID  file;  radiation  type,  location,  source  intensity;  and  ownship  location: 

-  equipment  functional  status  from  electric  power  indications  and  sustained  battle 

damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  the  areas  of  the  equipment  and/or  sensor 

-  detectable/not  detectable  from  radiation  type 

-  intensity  level  at  ownship  from  source  intensity  and  range  between  radiation 

source  location  and  ownship  location 

-  detcction/no  detection  from  radiation  ID  file  detection  threshold  and  radiation 

intensity  level  at  ownship 

-  radiological  alert  indication  and  other  interface  parameters  computed  and  passed 

-  detection  characteristics  can  be  modified  within  the  limits  of  the  radiation  warning 

adaptability  parameter 
NEEDED:  RWS  capabilities  description. 

Chemical  Warning  System  (CWSl 

Simulate  chemical  agent  detection  and  identification  performed  by  the  Chemical 
Warning  System  (CWS). 

Provide  detector  status,  agent  indications,  and  alerts  to  the  FSM. 
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The  intent  is  to  characterize  the  performance  of  the  CWS  by  defining  the  foliowiog 
a(h4)tabi]ity  parameters: 

-  sensitivity 

-  detecttH-  pattern 

>  catalog  of  known  agents  characteristics 

Check  the  design,  code  and  logic  to  verify  that  tl^  following  parameters  will  be 
properly  computed  in  accordance  with  the  chemical  warning  adaptability  parameters; 
chemical  ID  ffle;  chemical  type,  cloud  center  location,  cloud  radius,  cloud  density;  and 
ownship  location: 

-  equipment  functioiial  status  from  electric  power  indications  and  sustained  battle 

damage 

-  reduced  capability  or  total  failure  of  the  fimction  as  a  result  of  sustained  battle 

damage  in  the  areas  of  the  equipment  and/or  sensor 

-  detectable/not  detectable  from  chemical  type 

-  ownship  within/not  within  chemical  cloud  based  on  cloud  radius,  cloud  center 

location  and  ownship  location 

-  detection/no  detection  from  chemical  ID  file  detection  threshold  and  chemical 

density  level  at  ownship 

-  chemical  alert  indication  and  other  interface  parameters  computed  and  passed 

-  detection  characteristics  can  be  modifmd  within  the  limits  of  the  chemical  warning 

adaptability  parameters 
NEEDED:  CWS  capabilities  description. 

Chaff  M-I  M-130  Dispenser.  This  capability  is  not  currently  required  by  the  RAH-66. 
It  is  provided  here  for  information  purposes  only. 

Simulate  chaff  loading. 

Simulate  chaff  release. 

Simulate  chaff  system  status  and  inventory. 

Simulation  of  dispensed  chaff  characteristics  to  the  extent  to  provide  interface  to  the 
DIS  network  protocols. 

We  have  not  identified  a  validated  source  of  chaff  characteristics. 

Check  the  design,  code  and  logic  to  verify  that  the  following  parameters  will  be 
properly  computed  in  accordance  with  the  chaff  adaptability  parameters;  pilot  switch 
selection  and  actions;  and  ownship  locution: 

-  equipment  functional  status  from  electric  power  indications,  chaff  inventory,  chaff 

selection  and  sustained  battle  damage 

-  icduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  the  areas  of  the  equipment  and/or  dispenser 

-  chaff  dispensed  upon  command  when  manual  mode  selected 

-  chaff  dispensed  in  accordance  with  system  characteristics  or  adaptability 

parameters  when  automatic  mode  selected 

-  chaff  inventory  decremented  by  the  number  of  bundles  dispensed 

-  release  indication  and  other  interface  parameters  computed  and  passed 

-  delivery  system  characteristics  and/or  chaff  characteristics  can  be  modified  within 

the  limits  of  the  chaff  adaptability  parameters 
NEEDED:  Chaff  M-I  capabilities  description. 
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Flare  M-2n6  M-130  Dispenser.  This  capability  is  not  currently  required  by  the  RAH-66. 

It  is  provided  here  for  information  purposes  only. 

Simulate  flare  loading. 

Simulate  flare  release. 

Simulate  flare  system  status  and  inventory. 

Simulation  of  dispensed  flare  characteristics  to  the  extent  to  provide  interface  to  the 
DIS  network  protocols. 

We  have  not  identified  a  validated  source  of  flare  characteristics. 

Check  the  design,  code  and  logic  to  verify  that  the  following  parameters  will  be 
properly  computed  in  accordance  with  the  flare  adaptability  parameters;  pilot  switch 
selection  and  actions;  and  ownship  location: 

-  equipment  functional  status  from  electric  power  indications,  flare  inventory,  flare 

selection  and  sustained  battle  damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  the  areas  of  the  equipment  and/or  dispenser 

-  flares  released  upon  command  when  manual  mode  selected 

-  flares  released  in  accordance  with  system  characteristics  or  adaptability  parameters 

when  automatic  mode  selected 

-  flare  inventory  decremented  by  the  number  of  flares  dispensed 

-  release  indication  and  other  interface  parameters  computed  and  passed 

-  delivery  system  characteristics  and/or  flare  characteristics  can  be  modified  within 

the  limits  of  the  flare  adaptability  parameters 
NEEDED:  Flare  M'206  capabilities  description. 

Table  6.3.3.1.5  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 
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6.3.3. 1.6  RAH-66  Flight  Dynamics 
From  the  System/Segment  Specificatioa: 

"The  Flight  Dynamics  segment  shall  provide  for  a  realistic  simulation  of  the  flight 
characteristics  of  the  simulated  aircrafL  The  simulation  shall  include  portions  of  the  flight 
envelope  which  reflect  combat  operations  such  as:  ciuise,  ascent,  descent,  hover,  low-level 
(i.e.,  within  ground  effect)  flight,  a[^roach  and  landing  within  a  refueling^reaimament  zone 
and  subsequent  takeoff  from  that  zone.  The  simulation  shall  reproduce  Hdelity  of  flight 
operations  to  a  level  which  will  closely  resemble  that  of  the  selected  aircraft  and  which  will 
not  cause  either  distraction  of  the  pilot  or  an  increase  or  decrease  in  the  performance  of  the 
air  vehicle  to  an  extent  that  would  affect  combat  effectiveness  or  associated  test  results. 
The  simulation  shall  include  forces  and  moments,  equations  of  motion,  weight  and  balance, 
envelope  violation,  aerodynamics  and  ground  handling.  The  flight  dynamics  simulation 
shall  also  include  the  ability  to  set  and/or  adjust  certain  device  parameters  to  include 
maximum  speed,  fuel  load  time,  maximum  pitch,  roll  and  yaw  rates,  turning  radius,  turret 
and  hull  separation  distance,  number  of  blades  and  no  tail  rotor  effect  on  performance, 
failures  from  combat  and  crash  damage,  gross  weight  limitations,  external  fuel  tanks, 
weapons  selection,  wing  stores,  internal  stores  configuration  and  load  time  for 
ammunition." 

Check  the  design,  logic  and  code  in  the  foUowing  areas  to  verify  that  the  segment 
will  perform  as  specified: 

-  rotor  aerodynamics  computation  of  the  forces,  moments  and  torques  generated  by 

the  main  rotor  and  fantail  during  all  modes  of  operation 

-  airframe  aerodynamics  computation  of  the  aerodynamics  forces  and  moments 

generated  by  the  airframe  (i.e.,  fuselage,  vertical  tail,  horizontal  stabilizer, 
landing  gear  and  doors) 

-  ground  handling  computation  of  the  vertical  force  generated  by  the  interaction  of 

the  aircraft  landing  gear  with  the  ground 

-  mass  properties  computation  of  aircraft  gross  weight,  center  of  gravity  position, 

and  moments  and  product  of  inertia 

-  total  forces  and  moments  computation  of  the  total  forces  and  moments  acting  on 

the  aircraft  in  the  body  axis  coordinate  system 

~  envelope  violation  monitoring  capability  of  critical  flight  parameters  to  determine  if 
the  structural  capabilities  of  the  aircraft  have  been  exceeded  resulting  in  a 
crash  condition 

-  equations  of  motion  computation  of  aircraft  state,  which  include  linear  and  angular 

positions,  vclocides,  and  accelerations  in  both  the  body  and  earth  axis 
coordinate  systems 

-  ability  to  set  and/or  adjust  the  flight  dynamics  segment  adaptability  parameters 

-  simulation  of  the  effect  of  changes  in  the  physical  configuration/position  of  the 

aircraft  fuselage  components  and  degraded  flight  perfomumce  due  to  battle 
damage 
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Table  6.3.3. 1.6  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 
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Table  6.3.3. 1 .6  Logic  and  Code  Verification  Activities  for  RAH-66  Flight  Dynamics 


6.3.3. 1.7  RAH-66  Propulsion 

T800  Engine  Simulation 

Simulate  rotor  torque/speed  function 

-  main  rotor  speed 

-  tail  rotor  speed 

-  transmi.ssion  oil  temperature  and  pressure 
Simulate  gas  generator  function 

-  gas  generator  speed 

-  power  turbine  speed 

-  engine  oil  temperature  and  pressure 

-  engine  torque 
Simulate  engine  fuel  function 

-  fuel  rates 

-  turbine  gas  temperature 
Approach  to  simulation: 

Engine  oil  temperature  and  pressure  are  initialized  and  held  constant  unless  battle 
damage  has  occurred. 

Transmission  oil  temperature  and  pressure  are  initialized  and  held  constant  unless 
battle  damage  has  occurred. 

Power  turbine  speed  is  initialized  and  held  constant  unless  battle  damage  has 
occurred. 
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Check  the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  segment 
will  simulate  the  engines  and  transmission  of  the  RAH-66  as  specified: 

-  rotor  t(»que/q)eed  as  a  function  of  the  torque  requirements  generated  in  tte  flight 

dynamics  section 

-  engine  fuel  bum  rate  as  a  function  of  torque  ou4>ut  and  gas  turbine  qieed 

-  gas  generator  core  speed  modulation  to  maintain  the  100%  rotor  speed  demand 

-  ability  to  set  and/or  adjust  the  propulsion  segment  adaptability  parameters 

-  simulation  of  the  reactions  to,  and  indications  of,  sustained  battle  damage 

Table  6.3.3. 1.7  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 


Phase: 

Activity: 
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Table  6.3.3. 1 .7  Logic  and  Code  Verification  Activities  for  RAH-66  Propulsion 


6.3.3. 1.8  RAH-66  Physical  Cues 

"The  Physical  Cues  segment  shall  simulate  the  environmental  sounds,  navigation 
system  tones  and  threat  audio  tones  for  each  of  the  RAH-66  aircraft.  The  simulated  sounds 
shall  include  engines,  rotors,  small  arms  impacts,  ownship  weapons  firings  and  weapon 
detonation,.  Simulated  tones  shall  include  aircraft  warning  system  synthetically  generated 
tones,  radar  induced  tones,  and  navigation  systems  tones.  The  spectral  content  and 
loudness  levels  of  these  sounds  and  tones  shtdl  be  dynamically  controlled  to  represent 
realistic  responses  to  simulated  events.  There  shall  be  no  motion  system  or  motion  cues 
provided." 

SPARTA  shall  check  the  design,  logic,  and  code  to  verify  that  these  function  are 
implemented  as  specified. 
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Table  6.3.3. 1.8  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  dtiring  each  develo[»nent  phase  for  this  compr-ienL 
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Table  6.3.3. 1 .8  Logic  and  Code  Verifiodion  Activities  for  RAH-66  Physical  Cues 


6.3.3. 1.9  RAH-66  TNE 

The  Tactical  and  Natural  Environment  segment  will  receive  special  attention  for, 
through  it.  the  ARWA  SS  interfaces  with  the  rest  of  the  Multiple  Simulator  Environment 
(MSE).  And  since  these  data  then  flow  to  and  from  the  other  segments  of  the  RAH-66 
Simulator  System  Module,  in  order  to  interact  with/stimulate  their  models,  the  proper 
implementation  and  functioning  of  the  TNE  segment  is  crucial  to  the  proper  functioning  of 
the  entire  RAH-66  Simulator  System  Module.  Verification  will  require  a  check  of 
the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  segment  will  operate  as 
specified: 

TNE  Segment  Support  Function 

-  Executive  Control  support  service  which  provides  operational  control  for  the  'I'NE 

segment 

-  Initialization  support  service  which  controls  initial  hardware  and  software  states 

for  the  TT^  segment 

-  ARWA  SS  Inter-Segment  Communication  support  service  which  provides  the 

TNE  segment  interface  through  the  ARWA  SS  architecture 
Atmosphere  Function 

-  Provides  ambient  atmospheric  data  as  a  function  of  altitude 

-  Provides  the  specific  atmospheric  model 

-  Provides  commanded  atmospheric  effects  such  as  wind  and  turbulence 
Database  Management  Function 
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-  Provides  control  of  the  ARWA  SS  datalMaes  before,  and  during,  a  real-time 

experiment  This  function  shall: 

-  filter  out  those  entities  which  are  beyond  a  specified  range  in  order  to 

reduce  the  scope  of  actively  modeled  entities 

-  process  logical  and  data  faults  armind  the  gaming  areas 

-  provide  the  management  of  dynamic  database  elemoits,  as  a 

minimum,  the  location  of  platform  entity  crash  sites 

-  maintain  a  list  of  the  terrain  and  culture  points  within  the  gaming 

area  that  have  been  damaged,  or  otherwise  affected,  in  a  real-time 
exercise 

-  the  reference  database  provides  the  background  terrain  and  culture 

definition  required  for  resolution  of  ^atial  relations,  occulting,  etc. 
Spatial  Relations  Function 

-  Provides  models  that  characteriTc  the  relationship  between  a  vehicle  and  elements 

of  the  natural  and  tactical  cnvironmcnL  This  function  will: 

-  determine  the  slant  range  from  a  specified  entity  to  natural  and  tactical 

entities  in  the  gaining  area 

-  calculate  height  above  terrain,  for  a  specified  entity,  based  upon  the  terrain 

characteristics  contained  in  the  terrain  database 

-  detect  the  occurrence  of  collisions  between  a  specified  entity  and  entities  or 

terrain  with  udiich  it  can  collide 

Occulting  Function 

-  Determines  the  line-of-sight  continuity  between  any  object  or  deagnated  area  and 

the  ownship,  or  for  other  objects  in  the  simulation 
Entity  Management  Function 

-  Simulates  the  physical  characteristics  of  all  active  platforms  in  a  real-time 

experiment 

-  it  shall  use  the  appropriate  dead  reckoning  algorithms,  as  dcfuied  by  the 

MSE  for  each  entity  generated  by  the  MSE,  to  update  tlteir  position 
and  attitude  between  update  messages 

-  it  shall  integrate  the  updated  information  about  the  entity  state  in  order  to 

produce  a  seaiulc.s.s  simulation  of  the  entity  witiiin  the  owtishtp 
Entity  Database  Function 

-  Provides  an  extensive  and  detailed  description  of  the  non-ownship  entities  that 

may  be  a^ve  in  an  experiment,  it  shall  also  provide  for  the  generation 
and  maintenance  of  the  entity  data. 

Entity  Weapons  Function 

-  Simulates  the  firing  and  flight  track  of  weapons  detectable  to  the  ownship  during  a 

real-time  experiment  It  shall: 

-  activate,  fly  and  deactivate  non-ownship  weapons  in  accordance  with 

instructions  from  the  Entity  Management  function 

-  model  all  of  the  control  and  operation  parameters  for  weapon  entities, 

based  on  control  requests 

-  accept  command,  control  and  position  information  from  the  MSE 

Interaction  function  describing  weapons  which  are  created  and 
controlled  by  other  simulators  in  the  MSE 
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-  integrate  this  information  into  a  seamless  simulation  of  weapon  entities 

-  model  die  flight  path  fidelity  of  wet^n  entity 

-  model  the  mass  properties  of  wet^)on  entities 
Entity  Expendable  Countermeasure  Function 

-  Simulates  deployment  of  expendable  countermeasures  (e.g.  chaff  and  flares)  from 

non-ownship  platforms  during  an  experiment  Expendable 
countermeasures  dispensing  will  be  controlled  by  other  simulators. 

MSE  Interaction  Function 

-  Provides  the  communication  protocol  and  data  formats  required  for  interactitHi 

between  the  TNE  segment  and  the  MSE. 

-  The  MSE  interaction  functitm  shall  provide  all  formatting,  ctmversion,  and 

communication  required  for  the  TNE  segment  to  communicate 
within  the  MSE 

-  Communications  shall  use  the  DIS  protocol 

-  Communications  between  simulators  in  the  MSE  shall  occur  via  DIS 

LAN. 

Table  6.3.3. 1.9  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 


■  ifm  nr** 

1  Documentation  Review 

V 

V 

V 

V 

V 

iTTmn  :■■■ 

V 

1  Peer  Review 

V 

V 

1  Logic  Representation 

- 1 

_ 

V 

V 

1  Statistical  Test 

Table  6.  Logic  and  Code  Verification  Activities  for  RAH-66  TNE 


6. 3. 3. 2  AH-64D  Longbow  Kit 

6.3.3. 2. 1  AH-64D  Flight  Controls 

The  following  are  the  requirements  for  the  Flight  Controls  from  the  Sysiem/Segment 
Specification: 
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"The  flight  controls  segment  shall  simulate  the  flight  controls  of  the  AH-64D. 
Simulations  shall  include  primary  controls,  trim,  hinge  moments.  Enhanced  Digital 
Automatic  Stabilization  Equipment  (EDASE),  miscellaneous  control  devices,  and  toe 
brakes.  The  flight  controls  simulation  shall  also  include  the  ability  to  set  and/or  adjust 
certain  device  parameters  including  maximum  pik'h,  roll  and  yaw  rates;  turning  radius: 
flight  controls  input  sensitivity;  number  of  blades;  no  tail  rotor  effect  on  perfoiinaiK:e;  and 
stochastic  failures  from  combat  and  crash  damage  tables." 

"The  surface  positions  shall  be  determined  from  the  cockpit  control  device  inputs 
(cyclic  stick,  collective  stick  and  directional  pedals),  EDASE  inputs,  hydraulic  pressures, 
electrical  power,  and  malfunction  (battle  damage)  data.  The  primary  controls  function  shall 
include  the  simulation  of  surfaces  or  controls  such  as  actuators,  swashplates  and  blade 
pitch  (main  and  tail)." 

"The  "cyclic  trim"  or  "trim  feel"  function  shall  be  modeled  for  the  AH-64D.  This 
shall  include  the  force  acting  on  the  cyclic  stick  and  directional  control  pedals  to  center  and 
provide  an  artificial  feel  of  being  in  a  trim  state." 

"The  hinge  moments  function  shall  provide  a  simulation  of  hinge  moments  acting 
on  the  aerodynamic  control  surfaces  of  the  baseline  aircraft,  if  necessary,  and  shall  restrict 
movement  of  those  aerodynamic  surfaces  appropriately." 

"The  EDASE  simulation  shall  provide  the  capabilities  of  heading  hold,  attitude 
hold,  hover  hold,  and  altitude  hold  as  required  for  the  AH-64D.  Stability  augmentation 
simulations  shall  provide  improved  stability  in  the  pitch,  roll  and  yaw  axes  by  providing 
aircraft  damping.  The  stability  augmentation  system  shall  oppose  any  deviation  in  attitude, 
but  shall  not  return  the  aircraft  to  a  given  attimde  or  heading.  The  simulation  shall  provide 
for  stability  augmentation  to  be  engaged  at  all  times  in  pitch,  roll  and  yaw  mode.  Sensed 
rate  signals  and  Air  Data  System  (ADS)  inputs  shall  be  used  in  determining  pitching, 
rolling,  or  yawing  motion." 

"The  miscellaneous  controls  including  siabikloi  position  and  tail  wheel  locked 
status  shall  be  simulated  by  this  function.  The  normalized  positions  and  states  (e.g.,  open, 
opening,  closed,  etc.)  of  the  miscellaneous  control  devices  shall  also  be  determined  by  this 
function.  The  stabilator  position  for  the  AH-64  series  helicopters  simulation  shall  support 
manual  and  automatic  control  only." 

"The  simulation  of  braking  effects  shall  be  modeled  for  the  AH-64D  aircraft.  The 
AH-64D  shall  use  the  top  portion  (toe)  of  the  directional  control  pedals  to  provide  the  pilot 
control  of  the  main  gear  brakes.  The  effects  required  to  be  supplied  during  braking 
operation  shall  include  brakes  on  and  off.." 

Simulate  automatic  flight  controls  system  (EDASE)  by  modeling  EDASE  control 
laws  to  provide: 

-  stability  augmentation 

-  trim  hold 
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-  selectable  capabilities  fftmi  Table  6.3.3.2.1-1  betow; 


Pitch 

RoU 

Yaw 

Attitude 

Hover 

Velocity 

Hold 

Hold 

Hold 

Hold 

Hold 

Siiitslimion 

Y 

Y 

Y 

Y 

Y 

n/a 

Table  6.3.3.2. 1- 1  AH-6tf>  Flight  Controls  Setectable  Capabilities 


Check  the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  segment 
will  perform  as  specified: 

-  prinuuy  ccmtrols 

-  automatic  flight  controls  system 

-  flight  director 

-  miscellaneous  control  devices 

-  ability  to  set  and/or  adjust  the  flight  conools  segment  adaptability  parameters 

-  degradation  of  flight  controls  operation  due  to  battle  damage  based  on  severity  and 

location  of  damage 

Table  6.3.3.2.1-2  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  develoinnent  phase  for  this  component 
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HHHHHi 

HHBH 

1  Documentation  Review 

ii'i  irrrii'iTi  Hi  TIB 

V 

V 

1  Code  Verification 

'  i  it'  b  rrm'  i '  ■■■ 

V 

V 

V 

■■■■■ 

HHHHB 

1  Statistical  Test 

_ 

Table  6.3.3.2. 1-2  Logic  and  Code  Verification  Activities  for  AH-64D  Flight  Controls 


6.3.3.2.2  AH-64DNav/Comm 

INU  (Inertial  Navigation  Unit) 

From  the  System/Segment  Specification: 
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"The  AH-64D INU  simalation  slttU  imvide  helicopter  attitude  outputs  for  pitch, 
roll,  heading,  velocities,  and  accelerations  as  required  by  odier  aircraft  systems.  Align 
mode  control,  alignment  and  self  test  simulation  is  not  required.". 

DRVS  (Doppler  Radar  Velocity  Sensor) 

AN/ASN-157 

From  the  System/Segment  Specification: 

"Radio  Navigation  Aid  System.  SimulMion  of  DNS  accuracy  degradation  due  to 
altitude  and  high  pitch  and  roll  angles  is  not  required.  Modes  such  as  backup,  hover  bias 
calitoation,  and  test  modes  are  not  required.  Simulaticm  of  the  Initiated  Built  In  Test  (IBIT) 
function  is  not  required." 

GPS  (Global  Positioning  System) 

From  the  System/Segment  Specification: 

"A  generic  Global  Positioning  System  (GPS)  shall  be  modeled  to  provide  accurate 
position  and  velocity  information  for  use  by  other  systems." 

"This  information  will  be  derived  from  the  equations  of  motion  in  the  Flight 
Dynamics  segment,  then  modified  to  account  for  electrical  system  status,  battle  damage, 
and  adaptability  parameters." 

Communications 

ICS  (Intercommunications  System) 

C11746fARC 

VHFCOMMS-AM 

ARC>186 

VHFCOMMS-FM 

ARC-201 

UIIFCOMMS 

ARC-164 

Voice  communication.s  capabilities  of  the  above  subsystems  are  summed  into  one 
segment  to  provide  the  required  communication  capal^ties.  The  following  was  taken  from 
the  System/Segment  Specification  and  describes  the  required  communications  functionality. 

"Voice  reception  from  crewmembers  and  other  vehicles  shall  be  possible  at  all  times 
as  long  as  the  receiver  select  switches  on  the  ICS  panel  arc  on  and  the  volume  is  turned  up. 
The  simulation  shall  provide  for  monitoring  of  up  to  five  radios.  The  Hot  Mic  and  Mic 
switches  functions  are  not  required.  Nav  audio  (Automatic  Direction  Finder  (ADF)  or 
Identification  Friend  or  Foe  (H^)  monitoring  are  not  required." 

"The  ARC- 186  VHF  radios  shall  be  functional  in  AM  mode.  D/F  mode  simulation 
is  not  required.  Frequency  selection  shall  be  functional  in  the  manual  and  preset  modes  but 
not  in  emergency  mode.  Squelch  control  or  tone  select  functions  are  not  required. 
Insertion  of  static  and  noise  due  to  equipment  interference,  atmospheric  conditions,  or 
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range  is  not  required.  The  ability  to  receive  communications  shall  be  dependent  on  line  of 
sight  and  prc^r  (^ration  of  the  ICS  panel  selections.” 

”The  ARC- 164  UHF  radio  shall  be  fully  functional,  including  the  guard  receiver. 
Squelch  control,  and  tone  select  functions  do  not  require  simulatimi.  The  HAVEQUICK 
function  does  not  require  simulation.  Insertion  of  static  and  noise  due  to  equipment 
interference,  atmospheric  conditions,  or  range  is  not  required.  The  ability  to  receive 
communications  sh^  be  dependent  on  line  of  sight  and  proper  operation  of  the  ICS  panel 
selection." 

"The  ARC-201  VHF-FM  radios  shall  be  fully  functional.  Squelch  control  and  tone 
selection  functions  do  not  require  simulation.  The  SINCGARS  function  does  not  require 
simulation.  Insertion  of  static  and  noise  due  to  equipment  interference,  atmospheric 
conditions,  or  range  is  not  required.  The  ability  to  receive  communications  shall  be 
dependent  on  line  of  sight  and  proper  operation  of  ^e  ICS  control  panel  selections." 

AIR  DATA 

ADSS  (Air  Data  Sensor  System) 

Provide  the  following  information  to  the  other  ownship  systems: 

-  calibrated  and  indicated  airspeed 

-  temperature,  static  pressure,  and  all  air  mass  data 

-  hei^t  above  mean  sea  level 

The  above  data  is  modified  based  on  power  status,  battle  damage,  and  on/off 
adaptability  parameter. 

IMPROVED  DATA  MODEM  QDM) 

"The  IDM  shall  be  simulated  and  shall  interface  properly  through  the 
Communications  system.  IDM  communications  shall  be  possible  between  all  appropriately 
equipped  aircraft  and  the  Commander's  workstation  in  the  Tactical  Operations  Center 
(TOC).  The  IDM  system  will  enable  composition,  transmission  and  receipt  of  free  text,  RF 
handover,  pnority  fire/no  fire  zones,  battle  damage  assessments  and  other  pertinent  tactical 
data." 
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Table  6.3.3.2.2  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 


Phase: 

Activity: 
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HHIHiHi 
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■■■■■ 
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Table  6.3.3.2.2  Logic  and  Code  Verification  Activities  for  AH-64D  Nav/Comm 


6.3.3.2.3  AH-64D  Weapons 

McDonnell  Helicopter  Systems  has  proposed  two  options  for  the  modeling  of 
weapon  systems. 

The  first  option  is  to  use  existing  5  DOF  weapon  models  in  the  MDHC  model 
library.  These  S  DOF  models  were  validated  under  a  previous  effort  but  have  since  been 
modified.  This  option  would  allow  real-time  trajectory  generation  and  damage  assessment. 

The  second  option  is  to  generate  table  driven,  table  look-up  weapon  flyout  models 
derived  from  their  existing  5  DOF  model  library.  The  5  DOF  models  would  generate  die 
data  for  the  required  tables.  The  table  driven  models  arc  being  considered  based  on  1)  the 
computational  constraints  of  processing  time  available,  and  2)  ease  of  modification  of  the 
tabular  data  to  meet  experiment  needs  for  proposed  weapon  systems. 

The  acceptance  t)f  tiiese  table  driven  models  would  be  based  on  completion  of  all 
the  following  steps: 

-  review  of  the  validated  MDHC  5  DOF  weapon  trajectory  models  descriptions, 

-  comparison  of  the  validated  5  DOF  models  with  modified  5  DOF  models, 

-  review  of  the  previous  V&V  process,  and 

-  review  and  understand  the  translation  process  from  trajectory  model  to  table 

driven  model. 
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The  following  assumptimis  were  made  by  Boeing  for  the  Comanche  weapons  ami 
are  assumed  for  die  Lcmgbow  as  well  If  requirements  exist,  validation  of  mult^  Hellfiie 
systems  oe  performed  fmr  the  Comanche. 

-  no  simulated  gun  barrel  wear 

-  thrust  misalignment  due  to  down  wash  only 

-  yaw  and  projectile  drift  not  simulated 

-  port-staiboaid  eirms  not  simulated 

-  perfect  gunsights 

-  no  vibration  errors 

Check  the  design,  logic  and  cotte  in  the  computation  of  ownship  combat  damage. 
Determine  that  the  probabilities  of  kill  and  damage  are  properly  computed  as  a  function  of 
the  weapon  (warhead)  and  its  detonation  location  relative  to  predefined  aircraft  zones. 

M-230E1  3Qmm  Gun 

Represent  trajectory  of  ballistic  projectile  using  a  flyout  table.  Aerodynamic 
modeling  not  required.  Generate  dispersion  pattern  of  multiple  rounds  centered  on  a 
simulated  single  projectile. 

Compare  flyout  and  dispersion  patterns  logic  to  the  logic  implemented  in  the  model 
INCURSION  embedded  in  ALWSIM. 

Check  the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  system 
will  perform  as  speciHed: 

•  bullets  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  gun  can  be  selected  and  armed  (master  arm) 

-  gun  correctly  positioned  (AUTO/CLOSED/LOAD/DEPLOY) 

-  gun  can  be  targeted  within  correct  azimuth  and  elevation  limits 

-  gun  can  be  fired  -  trigger  1st  and  2nd  detent  operation 

-  rounds  remaining  decreases  properly 

-  bullets  follow  proper  trajectory  and  impact  about  targeted  point 

-  compute  all  data  required  by  ^vironment  segment  for  DIS  PDUs 
NEEDED:  M-230E1  30mm  Gun  capabilities  description. 

2.75"FFARMK-66 

Represent  trajectory  of  each  powered  projectile  using  a  flyout  table.  Aerodynamic 
modeling  not  required.  Generate  dispersion  pattern  centered  on  projectile  trajectory. 

Compare  flyout  and  dispersion  patterns  logic  to  the  logic  implemented  in  the  model 
INDIRECT  FIRE  EFFECfS  embedded  in  ,\LWSIM. 

Check  the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  system 
will  perform  as  specified: 

-  rockets  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  rockets  can  be  selected  and  armed  (master  arm) 

-  rockets  can  be  properly  targeted 

-  rockets  can  be  fired  -  trigger  1st  and  2nd  detent  operation 

-  number  remaining  decreases  properly 

-  rockets  follow  proper  trajectory  and  impact  about  targeted  point 

-  compute  all  data  required  by  Environment  segment  for  DIS  PDUs 
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NEEDED:  2.75"  FFAR  MK-66  capabiUties  description. 


I  K\*i  I  Vi  :l  PATa :« J  i  i  v 


Represent  trajectory  of  each  powered  missile  using  a  flyout  table.  Aerodynamic 
modeling  not  required.  Model  acquisititm  probability  as  a  function  of 

-  range  to  target 

-  laser  range  to  target 

-  reflected  energy 

-  background 

Use  PHI  model  in  ALWSIM  for  laser  target  acquisition  probability  comparison. 

Use  ALWSIM  flyout  logic  for  comparison  to  I^LFIRE  flyout. 

Check  the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  system 
will  perform  as  specified: 

-  missiles  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  missiles  can  be  selected  in  desired  sequence  and  armed  (master  arm) 

-  missiles  can  be  properly  targeted  to  obtain  "SHCXDT"  cue 

-  target  must  be  within  kinematic  range  of  missile 

-  target  must  be  designated  with  correct  code 

-  can  be  designated  autonomously  or  remotely 

•  seeker  must  acquire  (function  of  range/weather.  CLOS) 

-  designated  target  within  seeter  azimuth  and  elevation  FOV  limits 

-  aircraft  launch  constraints  must  be  met 

-  indirect  fire  and  lock-on-after-kumch  modes 

•  missiles  can  be  fired  -  trigger  1st  and  2nd  detent  operation 

-  missiles  fire  in  selected  order 

-  number  remaining,  and  their  location,  properly  displayed 

•  missiles  follow  proper  trajectory  and  impact  target 

-  compute  all  data  required  by  Environment  segment  for  DIS  PDUs 
NEEDED:  AGM-1 14A  LASER  HELLFIRE  capabilities  description. 


Represent  trajectory  of  each  powered  missile  using  a  flyout  table.  Aerodynamic 
modeling  not  required.  Model  acquisition  probability  as  a  function  of  range  to  target,  radar 
range  to  target,  and  target  radar  cross  section. 

Use  ACQUIRE  model  in  ALWSIM  for  radar  acquisition,  tracking  performance, 
and  probability  comparison. 

Use  ALWSIM  flyout  logic  for  comparison  to  HELLFIRE  flyout 

Check  the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  system 
will  perform  as  specified: 

-  missiles  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  missiles  can  be  selected  in  desired  sequeiK:e  and  armed  (master  arm) 

-  missiles  can  be  properly  targeted  to  obtain  "SHOOT’  cue 

-  target  must  be  within  kinematic  range  of  missile 

-  target  must  be  illuminated  with  correct  code 

-  can  be  designated  autonomously  or  remotely 

-  seeker  must  acquire  (function  of  range/weather,  CLOS) 
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-  designated  taiget  within  seeker  azimuth  and  elevation  FOV  limits 

-  aircraft  launch  constraints  must  be  met 

-  indirect  fire  and  lock-on-after-lumch  modes 

-  missiles  can  be  fired  •  nigger  1st  and  2nd  detent  operation 

-  missiles  fire  in  selected  order 

•  number  remaining,  and  their  location,  properly  displayed 

•  missiles  follow  proper  trajectory  and  impact  target 

-  compute  ail  data  required  by  Environment  segment  for  DIS  PDUs 
NEEDED:  AGM-1 14F  RF  HELLFIRE  capabilities  description. 


Represent  trajectory  of  each  powered  missile  using  a  flyout  table.  Aerodynamic 
modeling  not  required.  Model  acquisition  probability  as  a  function  of  range  to  target,  radar 
range  to  target,  and  target  radar  cross  section. 

Use  ACQUIRE  model  in  ALWSIM  for  radar  acquisition,  tracking  performance, 
and  probability  comparison. 

Use  ALWSIM  flyout  logic  for  comparison  to  HELLFIRE  flyout. 

Check  the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  system 
will  perform  as  specified: 

-  missiles  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  missiles  can  be  selected  in  desired  sequence  and  armed  (master  arm) 

-  missiles  can  be  properly  targeted  to  obtain  "SHOOT”  cue 

-  target  must  be  within  kinematic  range  of  missile 

-  target  must  be  illuminated  with  correct  code 

-  can  be  designated  autonomously  or  remotely 

-  seeker  must  acquire  (function  of  range/weather,  CLOS) 

-  designated  target  within  seeker  azimuth  and  elevation  FOV  limits 

-  aircraft  launch  constraints  must  be  met 

-  indirect  fire  and  lock-on-after-launch  modes 

-  missiles  can  be  fired  •  trigger  1st  and  2nd  detent  operation 

-  missiles  fire  in  selected  order 


-  number  remaining,  and  tlieir  location,  properly  displayed 

-  missiles  follow  proper  trajectory  and  impact  target 

-  compute  all  data  requited  by  Environment  segment  for  DIS  PDUs 
NEEDED:  AGM-1 14K  RF  HELLFIRE  n  capabUities  description. 
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Table  6.33.2.3  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 


1  Documentation  Review 

V 

V 

< 

V 

mmsmmmimiim 

V 

1  Code  Verification 

r  MiW 

Sensitivity  Analysis 

V 

Statistical  Test 

yl 

Table  6.3.3.2,3  Logic  and  Code  Verification  Activities  for  AH-64D  Weapons 


6. 3. 3. 2. 4  AH-64D  Sensors 

The  Night  Vision  and  Electronic  Sensors  Directorate  of  AMSAA  has  been  involved 
with  the  verification  and  validation  of  sensor  displays  in  the  past  and  should  be  involved 
with  our  current  effort  Previous  sensor  display  evaluation  at  AMSAA  have  focused  on  the 
results  of  an  initiative  on  the  ACQSIM  Simulation  for  Target  Acquisition. 

AN/ASO-llFLIRPNVS 

The  Visual  System  Module  (VSM)  computer  image  generation  (CIG)  system  (an 
ESIG-2()(X))  will  dedicate  one  of  its  channels  to  producing  the  FLIR  image.  Tlic  Ui.sk  i.s  to 
validate  that  the  ESIG-20(X)  properly  generates  IR  images  of  the  terrain  arid  moving 
models. 

SPARTA  does  not  have  any  means  of  generating  IR  imagerj'  from  the  terrain  and 
moving  model  data  bases.  We  could  usr^  FLIR90  to  generate  minimum  resolvable  contrast 
(MRC)  and  uiinimum  resolvable  temperature  differences  (MRTDs)  of  selected  targets  at 
selected  ranges,  at  selected  aspect  angles  against  selected  backgrounds  at  selected  times  of 
day  and  season.  We  would  then  have  to  extract  the  digital  image  from  the  ESIG-2(X)0 
under  the  same  selected  conditions  (1  don't  know  if  that's  possible).  The  extracted  image 
could  then  be  analyzed  to  determine  if  the  ESIG-2000  correctly  transformed  the  terrain  and 
moving  model  3D  representations  into  2D  IR  images. 

AN/AAai70TADS 

The  following  assumptions  were  made  by  Boeing  for  the  Comanche  EOTADS  and 
are  assumed  for  the  Longbow  as  well .  See  Boeing's  section  of  the  PMR  No.  2  briefing. 
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-  target  detection  and  classification  shall  be  probabilistically  determined  as  a 

function  of  range  to  target,  visibility,  and  adaptability  parameters 
(see  Faxed  material) 

-  frequency 
--  etc. 

-  target  prioritization  shall  be  a  functi(Hi  of  sensor  ID,  target  type,  and  range 

-  laser  range  error  will  be  a  function  of  the  adaptability  parameter 

Table  6.3.3.2.4  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 


V 

< 

V 

'V 

■iK^  rTTTfi  irmij 

V 

VT3 1  f  fTTt 

V 

1  Peer  Review 

V 

V 

V 

V 

1  Statistical  Test 

Table  6.3.3.2.4  Logic  and  Code  Verification  Activities  for  AH-64D  Sensors 


6.3.3.2.5  AII-64DASE 

Radar  Wciming  APR-39  (V)l  (V)2 
APR-48 

Simulate  RF  emitter  detection  and  identification  performed  by  the  Radar  Warning 
Receiver  (RWR). 

Provide  receiver  status,  RF  indications,  and  alerts  to  the  FSM. 

RF  indications  include  detection  range  and  parameter  limit  detection 
(RF,  PRF,  and  PW). 

The  intent  is  to  characterize  the  performance  of  the  RWR  by  defining  the  following 
adaptability  parameters: 

-  frequency 

-  PRF  (pulse  repetition  frequency) 

-  PW  (pulse  width) 

-FOV  (field  of  FOV) 

-  detection  range 
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•  direction  finding 

Check  the  design,  code  and  logic  to  verify  that  the  following  parameters  will  be 
properly  computed  in  accordance  with  the  radar  warning  adaptability  parameters;  EID  file; 
thrut  emitter  type,  location,  power,  mode,  and  beam  characteristics;  and  ownship  location 
and  orientation: 

-  equipment  functional  status  from  electric  power  indications  and  sustained  battle 

damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  the  areas  of  the  equipment  and/or  sensors 

-  identification  in  accordance  with  EID  file  and  emitter  beam  parameters 

-  maximum  detection  range  and  range  e^imate  from  ID,  EID  file  and  detected 

power 

-  detection/no  detection  from  maximum  range  and  threat  and  ownship  locations 

-  coarse  radar  site  list  for  radar  warning  receiver  and  radar  jammer  operation 

~  emitter  mode  (search,  acquisition,  track,  or  missile  activity)  from  EID  file  and 
emitter  beam  characteristics  and  activity 

-  emitter  relative  bearing  from  AOA  information  and  ownship  heading 

-  emitter  priority  based  on  priority  in  EID  file,  detecting  equipment  and  range 

-  emitter  location  based  on  range  and  bearing 

-  emitter  location  based  on  triangulation  processing  by  multiple  team  members 

-  radar  warning  indications  (up  to  8  visual  effects  and  up  to  5  visual  effects), 

prioritized  target  list  and  other  interface  parameters  computed  and  passed 

-  detection  characteristics  can  be  modified  within  the  limits  of  the  radar  warning 

adaptability  parameters 

NEEDED:  APR-39  (V)l  (V)2,  APR-48  capabilities  description. 

Radai- Jammer  ALQ-136  (V)l/5 

Simulate  the  matching  of  detected  RF  emitter  to  jamming  signal. 

Identify  detection  range  and  parameter  limits. 

Provide  radar  jammer  status  to  the  FSM. 

Provide  the  interface  to  the  DIS  network  protocols  for  the  transmitted  RF  signals). 
The  intent  is  to  characterize  the  performance  of  the  jammer  by  defining  lire 
following  adaptability  parameters: 

-  frequency 

-  power 

-  technique 

-FOV  (field  of  FOV) 

-  jam  range 

Check  the  design,  code  and  logic  to  verify  that  the  following  parameters  will  be 
properly  computed  in  accordance  with  the  radar  jammer  adaptability  parameters;  EID  file  ; 
course  radar  site  list;  and  ownship  location  and  orientation: 

-  equipment  functional  status  from  electric  power  indications,  ECM  enable  status 

and  sustained  battle  damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  the  areas  of  the  equipment  and/or  antennas 

-  emitter  detected  if  on  course  radar  site  list  generated  by  radar  warning  receiver 
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-  emitter  piimitized  in  aocmdance  widi  EID  file  and  range  between  emitter  site 

location  and  ownship  location 

-  AOA  evaluations  using  ownship  angular  position  values,  actual  earth  axis  azimuth 

and  elevation  to  the  emitter,  and  EID  file  error  indications 

-  radar  jamming  parameters  using  results  of  the  AOA  evaluations,  the  RF  emitter’s 

beam  parameters  and  the  EID  fite  jamming  indications 

-  RF  jamming  characteristics  required  to  effectively  simulate  the  jamming  of  the 

selected  emitters  (up  to  10)  and  other  interface  parameters  computed  and 
passed 

-  jamming  characteristics  can  be  modified  within  the  limits  of  the  radar  jammer 

adaptability  parameters 

NEEDED:  AL(J-136  (V)l/5  capabilities  description. 

Laser  Wamino  AVR-2(V)TBD 

Simulate  laser  emitter  detection  and  identification  performed  by  the  Laser  Warning 
Receiver  (LWR). 

Provide  receiver  status,  laser  indications,  and  alerts  to  the  FSM. 

The  intent  is  to  characterize  the  performance  of  the  LWR  by  defining  the  following 
adaptability  parameters: 

-  frequency 

-  PRF  (pulse  repetition  frequency) 

-  PW  (pulse  width) 

-FOV  (field  of  FOV) 

-  detection  range 

Check  the  design,  code  and  logic  to  verify  that  the  following  parameters  will  be 
properly  computed  in  accordance  with  the  laser  warning  adaptability  parameters;  laser  ID 
file;  laser  type,  location,  power,  code,  and  beam  characteristics;  and  ownship  location  and 
orientation: 

-  equipment  functional  status  from  electric  power  indications  and  sustained  battle 

damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  the  areas  of  the  equipment  and/or  sensors 

-  identification  in  accordance  with  laser  ID  file  and  laser  beam  parameters 

-  maximum  detection  range  and  range  estimate  from  ID.  laser  ^  file  and  detected 

power 

-  detection/no  detection  from  maximum  range  and  laser  and  ownship  locations 

-  laser  code  from  laser  ID  file  and  laser  beam  characteristics 

-  laser  relative  bearing  from  AOA  information  and  ownship  heading 

-  laser  priority  based  on  priority  in  laser  ID  file  and  range 

-  emitter  location  based  on  range  and  bearing 

-  emitter  location  based  on  triangulation  processing  by  multiple  team  members 

-  laser  warning  indications  (up  to  TBD  visual  effects  and  up  to  TBD  visual  effects), 

prioritized  target  list  and  other  interface  parameters  computed  and  passed 

-  detection  characteristics  can  be  modified  within  the  limits  of  the  IR  warning 

adaptability  parameters 

NEEDED:  AVR-2  (V)  capabilities  description. 
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IR  Jammer  alq-144  (V)1/3 

Simulate  IR  jamming  characteristics:  power,  frequency,  field  of  view. 

Provide  IR  jammer  status  to  the  FSM. 

Provide  the  interface  to  the  DIS  network  protocols. 

The  intent  is  to  characterize  the  performance  of  the  IR  jammer  by  defining  the 
following  a(hq)tability  parameters: 

-  frequency 

-  power 

-  technique 

Check  the  design,  code  and  logic  to  verify  that  the  following  parameters  will  be 
properly  computed  in  accordance  with  the  IR  jammer  adaptability  parameters;  IR  jammer 
characteristics;  location  of  IR  seeker;  and  ownship  location: 

-  equipment  functional  status  from  electric  power  indications,  ECM  enable  status 

and  sustained  battle  damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  the  areas  of  the  equipment  and/or  IR  element 

-  IR  jamming  parameters  for  simulation  of  the  cooldown  and  warmup  cycling 

technique 

>  IR  jamming  characteristics  and  other  interface  parameters  computed  and  passed 

-  jamming  characteristics  can  be  modified  within  the  limits  of  the  IR  jammer 

adr^tability  parameters 

NEEDED;  ALQ-144  (V)l/3  capabilities  description. 

Chaff  M-I  M- 130  Dispenser 
Simulate  chaff  loading. 

Simulate  chaff  release. 

Simulate  chaff  system  status  and  inventory. 

Simulation  of  dispensed  chafi  characteristics  to  the  extent  to  provide  interface  to  the 
DIS  network  protocols. 

Check  the  design,  code  and  logic  to  verify  that  the  following  parameters  will  be 
properly  computed  in  accordance  with  the  chaff  adaptability  parameters;  pilot  switch 
.selection  and  actions;  and  ownship  location: 

-  equipment  functional  status  from  electric  power  indications,  chaff  inventory,  chaff 

selection  and  sustained  battle  damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  the  areas  of  the  equipment  and/or  dispenser 

-  chaff  dispensed  upon  command  when  manual  mode  selected 

-  chaff  dispensed  in  accordance  with  system  characteristics  or  adaptability 

parameters  when  automatic  mode  selected 

-  chaff  inventory  decremented  by  the  number  of  bundles  dispensed 

-  release  indication  and  other  interface  parameters  computed  and  passed 

-  delivery  system  characteristics  and/or  chaff  characteristics  can  modified  within 

the  limits  of  the  chaff  adaptability  parameters 
NEEDED:  Chaff  M-I  capabilities  description. 
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Table  6.3.3.2.S  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 
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1  Documentation  Review 
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1  Flow  Dutgiam  Review 
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V 

HHHHH 

HHHHH 

HHHHHI 

Units  Check 

Logic  Representation 

yl 

Sensitivity  Analysis 

V 

StatisticalTest 

Table  6.3.3.2.5  Logic  and  Code  Verification  Activities  for  AH-64D  ASE 


6.3. 3.2.6  AH-64D  Flight  Dynamics 
From  the  System/Segment  Specification: 

"The  Flight  Dynamics  segment  for  the  AH-64D  will  be  adapted  from  the 
aerodynamic  model  that  exists  in  the  AH-64D  EDS  and  will  be  in  the  FORTRAN 
programming  language,  assuming  modifications  will  be  less  than  40%.  The  Flight 
Dynamics  segment  shall  provide  for  a  realistic  simulation  of  the  flight  characteristics  of  the 
simulated  aircraft.  The  simulation  shall  inclucte  portions  of  the  flight  envelope  which  reflect 
combat  opeiaiioas  such  as:  cniise,  ascent,  descent,  hover,  low-level  (i.e.,  within  ground 
effect)  flight,  approach  and  landing  witliin  a  refueling/rearmament  zone  and  subsequent 
takeoff  from  that  zone.  The  simulation  shall  reproduce  fidelity  of  flight  operations  to  a 
level  which  will  closely  resemble  that  of  the  selected  aircraft  and  which  will  not  cause  either 
dLstraction  of  the  pilot  or  an  increase  or  decrease  in  the  performance  of  the  air  vehicle  to  an 
extent  tliat  would  affect  combat  effectiveness  or  associated  test  results.  The  simulation 
shall  include  forces  and  moments,  equations  of  motion,  weight  and  balance,  envelope 
violation,  aerodynamics  and  ground  handling.  The  flight  dynamics  simulation  shall  also 
include  the  ability  to  set  and/or  adjust  certain  device  parameters  to  include  maximum  speed, 
fuel  load  time,  maximum  pitch,  roll  and  yaw  rates,  turning  radius,  number  of  blades  and  no 
tail  rotor  effect  on  performance,  failures  from  combat  and  crash  damage,  gross  weight 
limitations,  external  fuel  tanks,  weapons  selection,  wing  stores,  internal  stores 
configuration  and  load  time  for  ammunition.” 

Adaptability  parameters  are  being  reviewed  for  practicality  of  control.  The  final 
selection  of  adaptability  parameters  will  depend  on  the  completed  TSA/SFA. 
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Check  the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  segment 
will  perform  as  specified: 

-  rotor  aerodynamics  ccHnputation  of  the  forces,  moments  and  torques  generated  by 

the  main  rotor  and  fantail  during  all  modes  of  (^ration 

-  airframe  aerodynamics  computation  of  the  aerodynamics  forces  and  moments 

generated  by  the  airfiriune  (i.e.,  fuselage,  vertical  tail,  horizontal  stabilizer, 
landing  gear  and  doors) 

-  ground  handling  computation  of  the  vertical  force  generated  by  the  interaction  of 

the  aircraft  landing  gear  with  the  ground 

-  mass  properties  computation  of  aircraft  gross  weight,  center  of  gravity  position. 

and  moments  and  product  of  inertia 

-  total  forces  and  moments  computation  of  the  total  forces  and  moments  acting  on 

the  aircraft  in  the  body  axis  coordinate  system 

-  envelope  violation  monitoring  capability  of  critical  flight  paramctci's  to  determine  if 

the  structural  capabilities  of  the  aircraft  have  been  exceeded  resulting  in  a 
crash  condition 

-  equations  of  motion  computation  of  aircraft  state,  which  include  linear  and  angular 

positions,  velocities,  and  accelerations  in  both  the  body  and  earth  axis 
coordinate  systems 

•  ability  to  set  and/or  adjust  the  flight  dynamics  segment  adaptability  parameters 

-  simulation  of  the  effect  of  changes  in  the  physical  configuration/position  of  the 

aircraft  fuselage  components  and  degratted  flight  performance  due  to  battle 
damage 

Table  6.3.3.2.6  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component. 


Pre-PDR 

Post-CDR 

Logic  Verification 

Documentation  Review 

V 

V 

yl 

yi 

Flow  Diagram  Review 

Algorithm  Checks 

V 

Logic  Representation 

V 

1  Code  Walk-through 

V 

V 

1 

IHHH 

1  Logic  Representation 

1  Statistical  Test 

Table  6.3.3.2.6  Logic  and  Code  Verification  Activities  for  AH-64D  Flight  Dynamics 
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6.3.3.2.7  AH-64D  Propulsion 

Information  on  the  approach  and  design  criteria  for  the  AH-64D  propulsion 
segment  is  not  yet  available.  Although  MDHC  has  a  high  fidelity  model  of  the  GE-701 
engine,  it  is  anticipated  that  this  model  will  be  adapted  to  model  the  same  level  of  fidelity 
will  be  modeled  as  for  the  RAH-66. 

T701C  Engine  Simulation 

Simulate  rotor  toique/speed  function 

-  main  rotor  sp^ 

-  tail  rotor  speed 

-  transmission  oil  temperature  and  pressure 

Simulate  gas  generator  function 

-  gas  generator  speed 

-  power  turbine  speed 

-  engine  oil  temperature  and  pressure 

-  engine  torque 

Simulate  engine  fuel  function 

-  fuel  rates 

-  turbine  gas  temperature 
Approach  to  simulation: 

Engine  oil  temperature  and  pressure  are  initialized  and  held  constant  unless  battle 
damage  has  occurred. 

Transmission  oil  temperature  and  pressure  are  initialized  and  held  constant  unless 
battle  damage  has  occurred. 

Power  turbine  speed  is  initiali/ed  and  held  constant  unless  battle  damaged. 

Check  the  design,  logic  and  code  in  the  following  areas  to  verify  that  the  segment 
will  simulate  the  engines  and  transmission  of  tlie  AH-64D  as  specified: 

-  rotor  torque/speed  as  a  function  of  the  torque  requirements  generated  in  the  flight 

dynamics  section 

-  engine  fuel  burn  rate  as  a  function  of  torque  output  and  gas  turbine  speed 

-  gas  generator  core  speed  modulation  to  maintain  the  100%  rotor  speed  demand 

-  ability  to  set  and/or  adjust  the  propulsion  segment  adaptability  parameters 

-  .simulation  of  the  reactions  to,  and  indications  of,  sustained  battle  damage 
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Table  6.3.3.2.7  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  jriiase  for  this  cmnponenL 


Phase: 

Activitv: 

Pre-PDR” 

pinpcuR" 

Post-CM 

CUT 

Lofdc  Verification 

Documentation  Review 

V 

V 

>/ 

Design  Walk-throu^ 

V 

V 

Flow  Diagram  Review 

< 

Algorithm  Checks 

Logic  Representation 

V 

Code  Verification 

Code  Walk-through 

V 

Peer  Review 

V 

Units  Check 

V 

Logic  Representation 

Sensitivity  Analysis 

StatisticalTest 

Table  6.3.3.2,7  Logic  and  Code  Verification  Activities  for  AH-64D  Propulsion 


6.3.3.2.8  AH-64D  Physical  Cues 

"The  Physical  Cues  segment  shall  simulate  the  environmental  sounds,  navigation 
system  tones  and  threat  audio  tones  for  the  AH-64D  aircraft.  The  simulated  sounds  shall 
include  engines,  rotors,  small  arms  impacts,  ownship  weapons  firings  ard  v  .  apon 
detonation,.  Simulated  tones  shall  include  aircraft  warning  system  synthetically  generated 
tones,  radar  induced  tones  and  navigation  .systems  tones.  Tlie  special  content  and 
loudness  levels  of  these  sounds  and  tones  shall  be  dynamically  controlled  to  represent 
realistic  responses  to  simulated  events.  There  shall  be  no  motion  system  or  motion  cues 
provided." 

SPARTA  shall  check  the  design,  logic,  and  code  to  verify  that  these  function  are 
implemented  as  specified. 
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Table  6.3.3.2.8  shows  the  logic  and  code  verification  activities  that  are  to  be 
perfonned  during  each  development  phase  for  this  component 
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Table  6.3.3.2.8  Logic  and  Code  Verification  Activities  for  AH-64D  Physical  Cues 


6.3.3.2.9  AH-64DTNE 

The  Tactical  and  Natural  Environment  segment  will  receive  special  attention  for. 
through  it,  the  ARWA  SS  interfaces  with  the  rest  of  the  Multiple  Simulator  Environment 
(MSE).  And  since  these  data  then  flow  to  and  from  the  other  segments  of  the  AH-64D 
Simulator  System  Module,  in  order  to  interact  with/stimulate  their  models,  the  proper 
implementation  and  futictioning  of  the  TNE  segment  is  crucial  to  the  proper  functioning  of 
the  entire  AH-64D  Simulator  System  Module.  Verification  will  require  a  check  of  the 
design,  logic  and  code  in  the  following  areas  to  verify  that  the  segment  will  operate  as 
specified: 


Network  Interface  Function 

-  Provide  for  information  updates  conforming  to  the  Distributed  Interactive 

Simulation  (DIS)  standard. 

-  Provide  this  information  to  the  ongoing  simulation  of  the  ownship  environment  as 

appropriate. 

-  Perform  all  necessary  conversions  to  conform  to  ARWA  internal  data  formats  and 

units. 

Atmosphere  Function 

-  Provide  for  simulation  of  a  medium  fidelity  aonosphere. 

-  Simulate  air  mass,  global  winds,  and  turbulence. 

-  Provide  global  definitions  of  temperature  and  pressure. 

External  Entities  Function 
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-  Simulale  the  position  and  attitude  of  other  vehicles  between  iqidates  from  the 

raulti-simulattv  oivironment  (MSB). 

•  Upon  receiving  such  updates,  the  TNE  segment  shall  seamlessly  inject  the  new 
data  into  the  vehicle  simulation. 

Qwnship  Weapon  Damage  Fwiciion 

-  Provide  to  the  MSB  infonnation  regarding  ownship  weapon  path,  detonation  and 

ordinance. 

-  The  information  shall  be  passed  through  to  the  external  simulation  through  the 

Network  Interface  function. 

Threat  Weapon  Dynamics  Function 

-  Simulate  the  flight  of  threat  weapons  between  updates  from  the  MSB. 

Threat  Platform  Dynamics  Function 

-  Simulate  the  flight  of  threat  platforms  between  updates  from  the  MSB. 

Table  6.3.3.2.9  shows  the  logic  and  code  verification  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 
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Table  6.3.3.2.9  Logic  and  Code  Verification  Activities  for  AH-64D  TNE 
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7.0  VALIDATION  AGENDA 

The  structure  and  code  validation  procedures,  products,  and  data  requirements 
described  in  sections  7.1  and  7.2  represent  the  complete  set  of  activities  that  would  be 
performed  for  V&V  Intensity  Level  1.  The  specific  structure  and  code  and  model 
validation  activities  to  be  performed  for  each  ARWA  SS  component  are  defined  in  Section 
7.3. 


Prior  to  CDR,  the  V&V  team  will  identify  and  collect  or  generate  the  necessary 
data,  scenarios,  etc.  to  support  the  validation  tasks.  Agencies  such  as  BRL  and  AMSAA 
will  be  data  sources  for  several  areas  of  investigation.  Some  typical  real  world  data  sources 
that  SPARTA  intends  to  use  are: 

•  A  Compendium  of  Close  Combat  Tacdcai  Trainer  Data  Structures,  Algorithms, 
and  Generic  System  Mappings 

-  CASTFOREM.  This  is  a  combat  simulation  that  models  the  combat 
process  more  rigorously  than  the  force-on-force  model  GROUNDWARS.  CASTFOREM 
incorporates  the  effects  of  C3I,  nuclear-bilogical-chemical  weapons,  suppression,  laser 
weapons,  and  multi-target  scenarios  on  the  target  acquisition  and  engagement  process. 

-  GROUNDWARS.  This  force-on-force  combat  simulation  uses  Night 
Vision  Laboratory  (NVL)  models  to  characterize  the  target  acquisition  process. 

-  LORAM.  The  Low  Observable  Radar  Model  (LORAM)  is  a  one-on-one 
radar  perfromance  model  designed  to  predict  the  detectability  of  low  observable  targets  by 
battlefield  surveillance  radars. 

•TBD 

7.1  STRUCTURE  VALIDATION 

Structural  validation  focuses  upon  the  internal  portion  of  the  ARWA  SS  which 
includes  examination  of  the  assumptions  and  review  of  the  algorithms  and  architecture  in 
the  context  of  the  intended  use.  Structural  validation  will  examine  the  sensitivity  of  the 
simulator  modules  to  proper  data  input  items,  determine  whether  there  is  a  balance  of 
resolution  in  the  algorithms  /  modules,  determine  to  what  degree  the  simulator’s  modules 
represent  their  counterparts  in  the  "real-world",  and  determine  if  the  simulator  is  complete 
and  aU  the  necessary  functions  are  modeled. 

Tlie  two  areas  that  the  V&V  team  will  address  ia  the  validation  process  are  1) 
identification  of  the  “real  world”  being  modeled  in  each  software  segment,  and  2) 
identification  of  the  key  modeling  characteristics  and  output  parameters  in  each  software 
segment  that  are  to  be  used  in  the  comparisons.  Validation  involves  the  comparison  of  the 
simulator  behavior  and  results  to  data  obtained  from  another  credible  domain  that  is  either 
believed  to  be  the  "real  world",  or  has  been  proven  to  closely  approximate  the  "real  world", 
or  is  from  a  source  that  is  recognized  as  expert  on  the  relevant  characteristics  of  the  "real 
world".  The  standard  of  quality  that  the  simulator  is  expected  to  meet  is  a  part  of  this 
identiRcation  process.  This  is  a  critical  part  of  the  validation  process  because  the  "real 
world"  is  frequently  not  a  tangible  entity,  particularly  in  the  realm  of  combat  modeling.  For 
ARWA  SS  program,  the  primary  validation  reference  will  be  the  government  furnished 
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Task  and  Skills  and  Selected  Fidelity  Analyses.  The  V&V  team  references  will  also  be 
applied  as  consistency  checks.  In  addition,  the  V&V  team  will  identify  the  key  modeling 
characteristicc  and  output  parameters  for  each  of  the  modules  being  investigated  during  this 
phase  of  the  program. 

After  these  validation  tasks  have  been  performed,  the  V&V  team  will  integrate  the 
results  from  them  and  will  prepare  a  statement  of  credibility  that  will  state  the  capabilities 
and  limitations  of  the  models  in  each  software  segment 

The  specific  methods  that  the  V&V  team  will  employ  and  document  in  order  to 
validate  the  ARWA  SS  modules  are  described  in  the  following  paragraphs. 


7.1.1  Documentation  and  Reviews 

The  ARWA  V&V  team  will  review  the  ARWA  SS  specifications  and  design 
documents  prior  to  key  program  events  to  include  PDR  and  CDR. 

Upon  the  completion  of  validation  tasks  for  each  module,  a  report  will  be 
generated.  This  report  will  include  a  description  of  the  decomposition  and  the  level  of 
depth  achieved.  This  section  will  contain  the  evaluation  criteria  which  is  a  description  of 
the  "real  world"  to  include  a  description  of  the  data  that  was  chosen  for  comparison  and/or 
a  brief  background  of  SMEs  used.  Structural  validation  test  descriptions  and  results  will  be 
noted  plus  any  differences  compared  to  the  original  plan  of  effort.  The  methods  used  to 
perform  the  structural  validation  will  be  described.  The  same  detailed  information  will  be 
provided  for  output  validation  activities  performed.  Finally  in  this  section,  unresolved 
issues  will  be  noted. 
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Table  7.1. 1.1-1  PDR  Through  CDR  Phase  Validation  Data  Sources 


Procedures 

The  following  paragraphs  describe  the  procedures  that  can  be  used  from  PDR 
through  CDR. 

1.  Review  Detailed  Software  and  Interface  Design  Documents  against  the  Preliminary 
Software  and  Interface  Design  Documents  as  well  as  the  Software  and  Interface 
Requirements  Specification.  The  goal  as  before  is  to  assure  that  all  requirements 
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have  been  addressed  and  that  no  software  or  interfa<%  design  feature  exists  which 
can  not  be  matched  to  a  corresponding  requirement.  Enter  this  traceability 
information  in  the  V&V  documentation  to  support  further  traceability  efforts  at  the 
coding  and  unit  test  level.  Enter  any  discrepancies  into  the  discrepancy  and 
problem  tracking  data  base  maintained  by  the  CCB.  Identify  the  following  in  the 
V&V  Plan: 

•  Requirements  which  are  not  addressed, 

•  Software  and  Interface  design  features  which  do  not  support  a  higher-level 
requirement, 

•  Format  and  content  discrepancies. 

2.  Review  Software  Test  Plan  against  the  Software  and  Interface  Requirements 
Specification.  The  software  Test  Plan  defines  the  formal  qualification  tests  for  the 
CSCI,  the  software  test  environment  resources  required,  the  schedule  of  activities, 
and  the  individual  test  to  be  performed.  The  goal  of  this  review  is  on  the 
identification  of  test  which  will  provide  objective  evidence  that  the  CSCI  meets  its 
requirements.  Enter  this  traceability  information  in  the  V&V  documentation  to 
support  further  traceability  activities  at  the  coding  and  unit  test  level.  Enter  any 
discrepancies  into  the  discrepancy  and  problem  tracking  data  base  maintained  by 
the  CCB.  Identify  the  following  in  die  V&V  Plan: 

•  Requirements  for  which  no  test  is  identified. 

•  Tests  identified,  but  for  which  a  requirement  cannot  be  identified, 

•  Level  and  type  of  testing  to  be  performed  to  satisfy  each  requirement, 

•  Format  and  content  discrepaiK;ies. 

3.  Support  Reviews  and  Audits  by : 

•  Providing  briefing  books  containing  summary  status  information  for  each 
critical  CSCI.  Summary  inform;^  ion  will  include  software  size  estimates, 
schedule  (planned  versus  actual),  and  action  items  to  be  addressed  during 
the  meeting, 

•  Participating  in  the  review  as  directed  by  the  Prime. 
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Products 

Table  7.1. 1.1-2  describes  the  validation  products  generated  from  PDR  through 

CDR. 


Title 

DctcrlptloB 

Fornat 

Gald« 

FrcqacBcy 

V&VHan 

keport  on  the  completeness  of 
the  Preliminary  Software  Design 
Documents  (one  per  module) 

Once  per 
module 

'VWHan 

Report  on  the  completeness  of 
the  Preliminary  Interface  Design 
Documents  (one  per  module) 

TED 

Once  per 
module 

V&VPlan 

Report  on  the  completeness  of 
the  Detailed  Software  Design 
Documents  (one  per  module) 

TSD 

Once  per 
module 

V&VPlan 

Report  on  the  completeness  of 
the  Detailed  Interface  Design 
Documents  (one  per  module) 

TBD 

Onc*.^  per 
module 

VAVftan 

Report  on  the  completeness  of 
the  Software  Test  Plans  (one  per 
module) 

TBd 

Once  per 
module 

V&VPlan 

Briefmg  materials  reflecting  the 
status  of  each  modules 

TSD 

Once  per 
module 

Table  7. 1. 1. 1-2  PDR  Through  CDR  Phase  Validation  Products 


7. 1.1. 2  Post  CDR  through  Code  and  Unit  Test  (CUT)  Phase 
Data  Sources 

Table  7.1. 1.2-1  describes  the  data  sources  that  can  be  used  after  CDR  and  during 
the  code  and  unit  test  phases. 
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Description 


ottware 

Design 

Documents 

{Detailed) 


tcrfacc  Design 
Documents 
(Detailed) 


ource 
Software 
Development 
Files  (SDF) 


ottware  Test 
Plan 


ottware  Test 
Descriptions 


ottware  Test 
Reports 


Forniat 

Guide 


veiq;)meniai 
Configuration,  these  (Data 

represent  the  implementation  Accession 
of  the  design  (the  code)  and  List) 
the  rationale  supporting 
developer  implementation 
decisions  (the  SDF) 


uetmes  the  sottware  test 
environment  resources 
required,  the  schedule  of 
activities,  and  the  individual 
test  to  be  performed. 


Defines  the  test  cases  and  TBD  )DI 

procedures  needed  to  MCQl- 

perform  formal  qualification  80015A) 
testing  of  a  CSCl  in 
accordance  with  the  STP. 


Serves  as  a  record  ot  tte 
formal  qualification  testing 
performed  on  a  CSCL 


Document  Format  and 
Content  Requirements 


Table  7. 1 . 1 .2- 1  Post-CDR  Phase  Validation  Data  Sources 
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Procedures 

The  following  paragnq)hs  describes  the  data  sources  that  can  be  used  after  CDR  and 
during  the  code  and  unit  test  phases. 

1.  Review  Detailed  Software  and  Interface  Design  Documents  during  Coding  and 
CSU  Testing  and  CSC  Integration  and  Testing  phases.  This  revkw  compares  the 
SDD  and  IDD  products,  while  they  are  evolving  in  the  contractor  controlled 
E)evelopmental  Configuration,  against  the  Software  and  Interface  Requirements 
SpeciHcation  to  assure  that  all  requirements  continue  to  be  addressed  and  that  no 
software  or  interface  design  feature  exists  which  can  not  be  matched  to  a 
corresponding  requirement  Enter  this  traceability  information  in  the  V&V 
documentation  to  support  further  traceability  efforts  as  these  SDD  and  IDD  are 
updated.  Enter  any  dUcrepancies  into  the  discrepancy  and  problem  tracking  data 
base  maintained  by  the  CCB.  Identify  the  following  in  the  V&V  Plan: 

•  Requirements  which  are  not  addressed  by  design, 

•  Software  and  Interface  design  features  which  do  not  support  a  higher-level 
requirement, 

•  Format  and  content  discrepancies  based  on  the  contractor  specified  format. 

2.  Review  Source  Code  during  Coding  and  CSU  Testing  and  CSC  Integration  and 
Testing  phases  against  the  ^tailed  Software  and  hiterface  Design  Documents,  the 
Software  and  Interface  Requirements  SpeciHcation.  The  goal  as  before  is  to  assure 
that  all  requirements  have  been  addressed  and  that  no  software  or  interface  design 
feature  is  implemented  in  the  code  which  can  not  be  matched  to  a  corresponding 
requirement  Enter  any  discrepancies  into  the  discrepancy  and  problem  tracking 
data  base  maintained  by  the  CCB.  Itfentify  the  following  in  the  V&V  Plan: 

•  Requirements  which  ate  not  addressed  by  code, 

•  Software  and  Interface  code  features  which  do  not  support  a  requirement,  or 
trace  directly  to  design, 

•  Non-adherence  to  the  contractor’s  software  standards  and  procedures 
format  and  content  requirements. 

3.  Review  Software  Test  Descriptions  against  the  Software  and  Interface 
Requiferneiils  Specification  and  against  tlie  Sofiwaie  Test  Plan.  Tlie  softwaie  lest 
descriptions  begin  by  defining  test  cases  prior  to  CDR  and  continue  to  be  further 
refmed  by  defining  the  test  procedures.  The  goal  of  this  review  is  similar  to  the 
preceding  reviews,  however  we  are  focusing  on  the  idendftcation  of  the  speciftc 
lest  ca.ses  and  detailed  procedures  which  will  provide  complete  and  objective 
evidence  that  the  CSCI  meets  its  requirements.  Enter  this  traceability  information 
in  the  V&V  documentation  to  support  further  traceability  activities.  Enter  any 
discrepancies  into  the  discrepancy  and  problem  tracking  data  base  maintained  by 
the  CCB.  Identify  the  following  in  the  V&V  Plan: 

•  Requirements  for  which  no  test  is  identified  (our  Soundness  characteristic 
examines  die  adequacy  of  the  tests), 

•  Tests  identified,  but  for  which  a  requirement  cannot  be  identified, 

•  Format  and  content  discrepancies. 

4.  Review  Detailed  Softwaie  and  Interface  Design  Documents.  This  review  compares 
the  SDD  and  IDD  products  against  the  Softwaie  and  Interface  Requirements 
Specification  to  assure  that  all  requirements  have  been  addressed  and  that  no 
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software  or  interface  design  feature  exists  which  can  not  be  matched  to  a 
corresponding  requirement  l^ter  this  traceability  information  in  the  V&V 
documentation.  Enter  any  discrepancies  into  the  discrepancy  and  problem  tracking 
data  base  maintained  by  &e  CCB.  Identify  the  following  in  the  V&V  Plan: 

•  Specificatirms  which  are  not  addressed. 

•  Software  and  Interface  design  features  which  do  not  support  a  higher-level 
requirement 

•  Format  and  content  discrepancies. 

5.  Review  Software  Test  Reports  against  the  Software  and  Interface  Requirements 
Specification  and  against  the  Software  Test  Plan  and  Software  Test  Descriptions. 
The  STR  is  reviewed  for  test  completeness,  insuring  that  all  planned  tests  and 
procedures  ate  documented  with  results.  The  goal  of  this  review  is  to  determine 
that  all  tests  were  exercised  or  explanations  are  present  and  that  the  results 
provided  sufficient  objective  evidence  that  the  CSCI  meets  its  requirements.  Enter 
this  traceability  information  in  the  V&V  documentation.  Enter  any  discrepancies 
into  the  discrepancy  and  problem  tracking  data  base  maintained  by  the  CCB. 
Identify  the  following  in  the  V&V  Plan; 

•  Requirements  for  which  no  test  is  reported. 

•  Tests  identified,  but  for  which  a  requirement  carmot  be  identified, 

•  Test  results  which  do  not  support  the  objectives  of  the  STP  and  STDs, 

•  Tests  which  did  not  meet  satisfactory  completion,  or  achieve  conditions 
defined  in  the  STD  under  which  the  test  result  is  inconclusive, 

•  Format  and  content  discrepancies. 

6.  Support  Reviews  and  Audits  by : 

•  Providing  briefing  books  containing  summary  status  information  for  each 
critical  CSCI.  Summary  information  will  include  software  size  estimates, 
schedule  (planned  versus  actual),  and  action  items  to  be  addressed  during 
the  meeting, 

•  Participating  in  the  review  as  directed  by  the  Prime. 
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Products 

Table  7.1. 1.2-2  describes  the  validation  products  generated  after  CDR  and  the  code 
and  unit  test  phase. 


Descrq>tioa 


Report  on  the  completeness  of 
the  Detailed  Softv^  Design 
Documents  during  Coding.  CSU 
Testing,  CSC  Integraticm  and 
Testing. 


Report  on  the  completeness  of 
the  Detailed  Interface  Design 
Documents  during  Coding,  CSU 
Testing.  C51C  Integration  and 
Testing. 


Oeso^Mion 


VftVRnnat 

Guide 


VftV  Fonnat  Ftequency 
Guide 


eport  on  the  completeness  o 
the  Detailed  Software  Design 
Documents. 


ce  for  each 
critical  CSCI. 


Bnefing  book  reuecting  the 
status  of  each  critical  CSCI 
undergoing  review  or  audit 


Table  7 . 1 . 1 .2-2  Post-CDR  Phase  Validation  Products 
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7.1. 1.3  System  Integration  and  Test 

The  ARWA  V&V  team  will  review  die  results  of  the  individual  Segment  Code  and 
Unit  Test  evaluations  in  preparation  for  the  system  integration  and  test  The  team  will 
identify  any  perceived  possible  problem  areas  to  be  carefully  monitored  during  the 
integration  process.  These  possible  problem  areas  will  be  documented  prior  to  integration 
and  the  unique  test  procedures  may  be  imposed  to  assist  in  the  validation  of  the  segments 
involved  in  the  concerned  areas. 

The  V&V  team  will  support  any  and  all  reviews  associated  with  the  preparation  for 
system  integration  and  test  as  well  as  concurrent  to  the  integration  process  as  required  by 
the  Prime. 


7.1.2  Real  World  Comparisons 

Tite  ARWA  V&V  team  will  compare  tite  code,  ducumeiitaliun,  inpui  data,  and 
results  from  reference  “criteria”  models  with  models  from  the  ARWA  SS.  Thus,  for  this 
approach  to  be  meaningful,  the  reference  models  must  be  of  the  same  or  higher  fidelity  than 
used  in  the  ARWA  SS  and  must  be  accredited  for  use  in  a  similar  application. 

The  V&V  team  will  compare  the  code,  documentation,  input  data,  and  results  from 
reference  “criteria”  models  with  models  from  the  ARWA  SS.  Thus,  for  this  approach  to  be 
meaningful,  the  reference  models  must  be  of  the  same  or  higher  fidelity  than  used  in  the 
ARWA  SS  and  must  be  accredited  for  use  in  a  similar  application. 

To  actually  perform  the  comparisons,  the  V&V  team  will  make  up  input  data  sets 
for  both  the  ARWA  SS  and  reference  models,  run  the  models,  then  compare  the  results. 
Where  possible,  the  V&V  team  will  obtain  data  sets  for  the  reference  models  directly.  In 
these  cases,  the  V&V  team  will  develop  identical  (or  equivalent)  input  data  sets  for  the 
ARWA  SS  models,  have  ihe  models  run,  and  compare  the  results.  A  judgment  will  then  be 
made  as  to  whether  the  results  compare  closely  enough  to  deem  the  models  validated.  The 
V&V  team  will  pre-establish  tolerances,  parameter  by  parameter,  on  which  to  base  its 
judgment  for  the  variables  of  interest 


7.1.3  Software  Architecture  Assessment 

This  “piece-wise  validation”  approach  provides  a  logical  means  of  performing 
piece-wise  test  design,  testing,  and  analysis  of  large,  complex  simulations  like  the  ARWA 
SS.  The  V&V  team  will  divide  the  ARWA  SS  into  its  software  segments  and  these,  in 
turn,  will  be  divided  into  their  functional  elements.  The  V&V  team  will  then  bring  in 
subject-matter  experts,  as  required  to  supplement  its  V&V  team,  to  examine  the 
documentation,  code,  and  ouq)ut  and  determine  the  degree  of  fidelity  that  is  represented  in 
each  functional  area. 
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This  ‘*piece-wise  validation”  approach  provides  a  logical  means  of  performing 
piece-wise  test  design,  testing,  and  analysis  of  large,  complex  simulations  like  the  ARWA 
SS.  The  V&V  team  will  divide  the  ARWA  SS  into  its  software  segments  and  these,  in 
turn,  will  be  divided  into  their  functional  elements.  The  V&V  team  will  then  bring  in 
subject-matter  experts,  as  required  to  supplement  its  V&V  team,  to  examine  the 
documentation,  code,  and  ouq)ut  and  determine  the  degree  of  tidelity  that  is  represented  in 
each  functional  area. 


7.1.4  Face  Validation  (SME  Review) 

Face  validation  relies  on  the  opinion  of  subject-matter  experts  as  to  whether  the 
behavior  of  each  software  segment,  or  its  component,  is  “reasonable.”  This,  by  defmition, 
provides  a  subjective  assessment  of  the  vali^ty  of  the  models  and  serves  as  a  point  of 
departure  for  a  more  comprehensive  validation.  The  V&V  team  will  assemble  this  team  and 
participate  in,  and  guide,  its  activities. 

The  V&V  personnel  and  other  competent,  objective  reviewers  who  are  independent 
of  the  model  developer  will  conduct  a  detailed  verification  and  validation  review.  This  may 
overlap  with  the  functional  decomposition  phase  in  that  some  of  the  same  people  may  be 
involved.  In  the  independent  reviews,  ^e  scope  of  activities  is  somewhat  greater, 
however,  in  that  the  reviewers  will  examine  the  verification  and  validation  methods 
performed  by  the  model  developer,  in  addition  to  performing  a  detailed  verification  and 
validation  of  the  models. 

The  V&V  personnel  and  other  competent,  objective  reviewers  who  are  independent 
of  the  model  developer  will  conduct  a  detailed  verification  and  validation  review.  This  may 
overlap  with  the  functional  decomposition  phase  in  that  some  of  the  same  people  may  be 
involved.  In  the  independent  reviews,  ^e  scope  of  activities  is  somewhat  greater, 
however,  in  that  the  reviewers  will  examine  the  verification  and  validation  methods 
performed  by  the  mode)  developer,  in  addition  to  performing  a  detailed  verilicalion  and 
validation  of  the  models. 

Face  validation  relies  on  the  opinion  of  subject-matter  experts  as  to  whether  the 
behavior  of  each  software  segment,  or  its  component,  is  “reasonable.”  This,  by  definition, 
provides  a  subjective  assessment  of  the  validity  of  the  models  and  serves  as  a  point  of 
departure  for  a  more  comprehensive  validation.  The  V&V  team  will  assemble  this  team  and 
participate  in,  and  guide,  its  activities. 

7.2  OUTPUT  Validation 

7.2.1  Evaluate  T&E  Criteria 

The  ARWA  V&V  team  will  review  and  submit  for  revision  or  update  comments  or 
concerns  on  the  methods,  procedures,  and  quantitative  bounds  to  be  implemented  in  the 
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Testing  and  Evaluation  of  the  Segment  and  System  results.  The  team  will  base  all 
comments  and  concerns  upon  the  requirements  specified  in  the  documentation  maintained 
by  the  CCB  (SSS,  SRS,  IRS,  STP,  and  STD).  Additionally,  the  team  will  utilize  expert 
sources  to  obtain  concems/comments  on  the  possible  "feel”  which  should  be  expected.  All 
V&V  team  information  will  be  documented  and  presented  to  the  Prime  and  subcontractors. 


7.2.2  Data  Collection 

The  ARWA  V&V  team  will  review  and  submit  for  revision/update 
comments/concems  on  the  data  collection  methods  and  procedures  as  well  as  the  exact  data 
items  required  for  validation  of  segments.  The  team  will  base  all  comments  and  concerns 
upon  the  requirements  specitied  in  the  documentation  maintained  by  the  CCB  (SSS,  SRS, 
IRS,  STP,  and  STD).  Additionally,  the  team  will  utilize  expert  sources  to  obtain 
coiicerns/coinments  on  the  possible  "feel"  which  should  be  expected.  Tlie  V&V  team 
should  also  have  an  opportunity  to  interview  the  personnel  selected  to  pilot  the  simulator 
during  the  system  integration  tests  in  order  to  obtain  their  prioritization  of  sensory  cues. 
All  V&V  team  information  will  be  documented  and  presented  to  the  Prime  and 
subcontractors. 


7.2.3  Scenario  Identification 

The  V&V  team  will  review  and  submit  for  revision/update  comments/concems  on 
the  planned  scenarios  used  to  validate  the  segments  and  the  system.  The  scenarios  will  be 
compared  to  the  requirements  which  must  be  tested  to  insure  that  nominal  and  stressing 
conditions  are  tested  against  each  requirement  The  number  of  events  and  complexity  of 
mission  will  be  evaluated  to  insure  a  limited  set  of  scenarios  (runs)  will  be  required  to 
validate  the  segment  and/or  system.  AH  V&V  team  information  will  be  documented  and 
presented  to  Uie  Prime  and  subcontractors. 


7.2.4  Models 

Prior  to  CDR,  the  V&V  team  will  identify  and  collect  or  generate  the  necessary 
models  to  support  the  validation  tasks.  This  collection  of  models  will  range  from  the 
module  /  algorithm  level  to  the  system  level  and  will  also  cover  the  range  of  resolution  from 
high  to  low.  Some  of  these  models  will  be  used  to  generate  the  data  base  inputs. 

The  V&V  team  will  obtain  models,  where  available,  of  the  same  or  higher  fidelity 
than  used  in  the  ARWA  SS  which  are  accredited  for  use  in  a  similar  application.  These  will 
be  used  where  need  is  indicated  as  consistency  checks  on  the  government  Task,  Skills  and 
selected  Fidelity  Analyses.  A  partial  list  of  potential  models  for  consideration  in  this  task  is 
shown  in  Tables  7.2.4- 1  A,  -IB,  and  -1C.  TTiis  list  of  models  will  be  expanded  during  the 
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execution  of  this  ta^.  The  Tactical  EnvircMiment  SimulaUH*  (TES)  and  ALWSIM  are  in- 
house  SPARTA  capabilities  and  are  discussed  in  detail  below. 

TABLE  7.2.4-1A  CANDIDATE  MODEL  LIST 


NAME 

TYPE 

ALWSIM 

System  Level  Smiation 

HELMATES 

%stem  Level  Erigageniert  Sirnulation 
(Few  on  Few) 

TES 

Tadcal  Bi\«txirnerTt  Sirnulator 

EVADE 

System  Level  Engagement  Model 

INCURSION 

One  on  One  System  Level 

Engagement  Simulation 

TRAP 

Weapon  Model 

P001A 

Weapon  Model 

CNVEO  Target  Acquisition  Model 

Passive  Target  Acquisition  Model 

AIRADE 

Radar  Model 

TRAM 

Radar  Model 

DMEWS 

RF  Etf^  Model 

MIVAC 

Vulnerability  Assessment  Model 

Mariufacturet's  Engneering 
omuisiion 

Flight  Dynamics 
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TABLE  7.2.4-lB  CANDIDATE  MODEL  LIST  -  AH-64D 


AIRCRAFT 

SUBSYSTEM 

FUNCTION 

MODEL  IDENTIFIED 

AH-64D 

M-230E130MMGl)N 

INCURSION 

2.75"  FFAR  MK-66 

INDIRECT  HRE  EFFECTS 

AGM-1 14A  LASER  HELLFIRE 

PHI,  ALWSIM 

AGM-1 14F  RF  HELLFIRE 

ALWSIM 

AGM-114K  RF  HELLFIRE  II 

ALWSIM 

AN/AAQ-llFLIRPNVS 

FLIR  90 

AN/ASQ-170TADS 

ALWSIM 

FLIR 

ALWSIM 

mv 

ALWSIM 

DVO 

ALWSIM 

I.RF/T) 

iH)  III!  Kiel 

LS17L\T 

no  model 

IHADSS 

no  model 

HDU 

no  model 

SSU 

no  model 

DAP 

no  model 

SEU 

no  model 

DEU 

no  model 

FCR 

ACQUIRE 

TABLE  7.2.4-IC  CANDIDATE  MODEL  LIST  -  RAH-66 


^IRCRA^ 

SUBSYSTEM 

FUNCTION 

MODEL  IDENTIFIED 

RAH-66 

VULCAN  11 20  MM  GUN 

INCURSION 

HYDRA  70 

no  model 

2.75"  Fl'AR  MK-66 

INJJIRECT  HRE  EFFECTS 

AGM-114A  LASER  HELLHRE 

PHI,  ALWSIM 

ATAS 

ALWSIM 

NVPS 

(FLIR  90) 

EOTADS 

FLIR 

ALWSIM 

ALWSIM 

DTV 

ALWSIM 

DVO 

ALWSIM 

LRF/D 

no  model 

LST/IAT 

no  model 

FCR 

TBD 

ACQUIRE 
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7.2.5  Test  and  Evaluation 

Test  and  Evaluation  tasks  take  place  primarily  after  CDR  and  continue  through  the 
end  of  the  program.  These  tasks  are  applied  to  the  simulator  and  they  define  how  well  the 
simulator  results  compare  with  the  perceived  "real- world".  They  also  determine  whether 
the  simulator  output  is  what  is  expected  given  the  input  /  scenario.  The  test  and  evaluation 
tasks  will  employ  many  of  the  same  methods  discussed  in  Section  6.3.  During  this  stage 
of  testing,  some  of  these  methods  are  expanded  to  include  module  output  in  the  comparison 
to  the  "real  world”  standards  in  the  evaluation  whereas  during  structural  validation  testing, 
the  module  output  was  not  necessarily  considered. 


7.2. 5.1  Stress  Test  and  Sensitivity  Analysis 

Tlie  V&V  team  will  conduct  au  analysis  of  the  sensitivity  and  stress  test  results  that 
are  perfonned  in  tlie  veiificatioti  effort.  Tliese  data  will  be  reviewed  by  the  V&V 
personnel  and  other  subject-matter  experts  to  check  the  validity  of  the  model  outputs  for  the 
conditions  considered.  Since  the  V&V  team  anticipates  that  it  will  have  done  a  significant 
amount  of  testing  during  verification,  there  will  be  a  complete  set  of  data,  covering  all  of 
the  software  segments,  for  the  subject-matter  experts  to  analyze.  The  reviewers  will  check 
for  proper  responses,  given  the  input  and  changes  in  input. 

Each  validation  task  will  address  some  portion  of  the  questions  ioentified  as  part  of 
the  validation  plan.  Each  task  will  identify  the  method,  tools,  or  techniques  needed  to 
perform  the  task,  and  identify  the  data  values,  algorithms,  etc.,  to  be  compared.  The 
resulting  analysis  will  address: 

1 .  The  sensitivity  of  the  model  outputs  to  inputs  and  parameters  and  how  this 
compares  to  the  major  influeiK;ing  factors  in  the  baseline  "real  world". 

2.  The  assumptions  made  by  model  developers  and  their  impact  on  model 
usage  and  whether  or  not  these  assumptions  seriously  affect  the  model's 
ability  to  portray,  explain  or  predict 

3 .  The  interfaces  between  model  objects  /  processes  and  how  well  they  parallel 
the  established  baseline  interactions 

4.  The  completeness  and  balance  of  the  model  logic  across  the  model 
components. 

Model-Test-Model 

It  is  possible,  if  not  probable,  that  the  outputs  of  some  of  the  models  will  not  be 
consistent  with  data  obtained  from  validated  .sources.  When  conducting  the  stress  test  and 
sensitivity  analysis,  the  V&V  team  will  look  at  the  results  of  the  comparison  between  model 
and  “real-world”  outputs  to  determine  which  models  can  realistically  be  modified  to  yield 
more  credible  results.  Under  these  conditions  the  model  should  be  modified  or  fine  tuned 
to  make  its  output  consistent  with  “real  world”  data.  Where  modifications  are  required,  the 
V&V  team  will  document  the  inconsistencies  thoroughly  and  will  what  modifications  could 
yield  a  more  valid  model.  The  V&V  team  will  transmit  these  results  to  the  Army  and  the 
developer  at  as  early  a  date  as  possible  as  candidate  modifications  to  be  implemented  into 
the  ARWA  SS. 
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Similar  to  the  structural  validation  tasks,  each  test  and  evaluation  task  will  address 
some  portion  of  the  questions  identiHed  as  part  of  the  validation  plan  generated  during 
phase  I  of  this  program.  Each  task  will  identify  the  method,  tools,  or  techniques  needed  to 
perform  the  task,  and  identify  the  data  values,  algorithms,  etc.,  to  be  compared.  The 
resulting  analysis  will  address: 

1 .  The  sensitivity  of  the  model  outputs  to  inputs  and  parameters  and  how  this 
compares  to  the  major  influencing  factors  in  the  baseline  "teal  world". 

2.  The  assumptions  made  by  model  developers  and  their  impact  on  model 
usage  and  whether  or  not  these  assumptions  seriously  affect  the  model's 
ability  to  portray,  explain  or  predict 

3 .  The  interfaces  between  model  objects  /  processes  and  how  well  they  parallel 
the  established  baseline  interactions 

4.  The  completeness  and  balance  of  the  model  logic  across  the  model 
components. 

After  these  validation  tasks  have  been  peifomted,  SPARTA  will  integrate  the  results 
from  them  and  will  prepare  a  statement  of  credibility  that  will  state  the  capabilities  and 
limitations  of  the  models  in  each  software  segment 


The  Tactical  Environment  Simulation  (TES)  facility  is  proposed  for  use  as  a 
simulator  V&V  tool  for  accomplishing  validation  of  DIS  interaction.  This  facility  provides 
a  realistic,  real-time  tactical  environment  for  embedding  ARWA  developed  elements  for 
both  verification  and  validation  testing.  The  environment,  available  via  DIS  message 
streams,  is  comprised  of  opposing  and  friendly  air  and  ground  forces  including  aircraft, 
EW  radars,  command  and  control  network,  SAMs,  and  AAA.  It  has  two  manned  pilot 
stations  networked  to  it,  and  the  entire  facility,  or  elements  of  it,  can  be  networked  to 
manned,  dome  simulators  or  interact  with  the  ModSAF  SAPOR  using  the  DIS  protocol. 

When  so  networked,  TES  would  provide  realistic  stimuli  to  the  manned  simulators, 
which,  in  the  ARWA  SS  V&V  application,  will  permit  the  lest  and  evaluation  of  device 
sensors,  targeting  systems,  weapons,  and  ASE  in  a  manner  that  will  yield  credible 
verification  and  validation  results.  A  specific  example  is  described  following  the  TES 
hardware  description.  A  block  diagram  of  the  TES  architecture  is  presented  in  Figure 
7.2.5.1-1.  TES  is  hosted  on  a  VAX-3540  in  the  TES  facility  but  is  hosted  on  a  wide  range 
of  VAX’s  in  other  installations. 
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The  primary  pilot  station  comprises  the  following  elements: 

-  SGI  ONYX/2  RE^  for  presentation  of  the  out-the-window  di^lay  and  the 
HUD 

-  SGI  4D/320VGXT  for  the  head-down  display  that  presents  the  in-cockpit 

controls  and  displays 

-  set  of  Hands-on-Throttle-and-Stick  (HOTAS)  flight  controls 

-  touch  screen  mounted  on  the  head-down  display 

-  pilot  station  enclosure. 

An  auxiliary  pilot  station  comprises  the  following  elements: 

-  SGI  4D/120GTX  that  presents  a  composite  out-the-window  display,  HUD, 
and 

head-down  display 

-  set  of  generic  HOTAS  flight  controls 

-  touch  screen. 


Use  of  the  Tactical  Environment  Simulation 

The  I'actical  Environment  Simulation  (TES)  would  be  placed  on  the  network  in 
order  to  provide  realistic: 

a)  targets  for  the  sensors  to  detect, 

b)  ground  and  aircraft  targets  to  be  targeted  and  fired  at  with  the  aircraft’s 
weapons, 

c)  threat  radars  which  will  activate  RWRs  and  against  which  RF  jammers  can 
be  employed,  and 

d)  threat  missiles  which  will  activate  IRWRs  and  against  which  IR  jammers, 
chaff,  and  flares  can  be  employed. 

This  system  is  proposed  for  use  at  the  earliest  practical  r  ,ge  of  the  development 
process  to  provide  a  re^istic  test  environment  for  a  "test  it  as  you  would  fight  it"  approach 
to  validation.  The  development  of  subsystem  software  modules  so  they  could  interface 
with  the  DIS  netwoik  would  permit  embedding  them  in  a  validated  threat  environment  and 
exercising  their  response  over  the  full  design  range.  In  this  way  software  elements,  like 
individual  sensor  or  weapon  systems,  can  be  tested  against  tactical  elements  at  an  early 
stage,  prior  to  as  well  as  after  system  aggregation.  This  testing  is  not  intended  to  replace 
conventional  unit,  segment,  device  and  system  test,  but  will  supplement  it  in  a  way  that  will 
enhance  credibility  and  likely  accelerate  simulator  acceptance  testing.  As  a  specific  example 
consider  testing  of  tlie  ARWA  radar.  With  TES:  the  ra«Jar  would  be  positioned  at  a  specihe 
position  and  altitude  within  the  gaming  area.  Target  aircraft  would  then  be  positioned  at 
desired  locations  within  the  gaming  area,  at  different  altitudes,  to  determine  the  radar's 
ability  to  detect  targets  of  known  or  specified  radar  cross-section  in  the  presence  of  clutter. 
Tests  could  be  rapidly  conducted  at  many  combinations  of  sensor  altitude,  target  altitude, 
range  and  cross-section  and  radar  mode  to  test  if  the  radar  behaves  according  to 
specification  (verification)  and  in  a  realistic  manner  (validation).  Following  these  tests, 
effects  of  jamming  on  detection  range  could  be  evaluated  including  bum-through  ranges. 
Similarly,  the  effects  of  ownship  warning  receivers,  jammers,  weapons  or  other 
subsystems  that  interact  with  tactical  elements  or  terrain  can  be  tested. 
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An  upgrade  to  DIS  2.0  protocols  and  integration  into  the  test  LAN  at  the 
development  site(s)  would  be  required  to  implement  this  capability. 

The  full  up  simulator  would  be  validated  during  engagement  with  TES  and 
ModSAF  threats  using  a  combination  of  subjective  evaluation  (cognizant  pilots  with 
applicable  experience)  and  objective  evaluation.  The  goal  will  be  to  ensure  that  the 
simulators  readistically  represent  the  flight  dynamics  and  crew  environment  of  the  actual 
aircraft 

ALWSIM  -  Qose  Combat  Simulation 

SPARTA  has  extensive  experience  in  the  development  and  use  of  large  scale 
battle/combat  simulations  relating  to  land  combat  systems,  air  defense  systems,  command 
and  control  systems,  flxed  and  rotary  winged  aircraft  and  strategic  weapon  systems. 
SPARTA  has  developed  the  Army  Laser  Weapon  Simulation  (ALWSIM).  which  is  a  high 
resolution  combined  anus  simulation  of  close  combat  between  opposing  forces  that  may 
include  armor,  artillery,  infantry,  aircraft  and  air  defense.  ALW’SIM  is  primarily  a  to< 
performing  system  effectiveness  and  directed  energy  weapon  analysis.  DA^A  c 
SPARTA  to  use  ALWSIM  to  validate  the  performance  of  the  SIMNET-D.  Several  key 
features  of  ALWSIM  include;  modeling  of  Uu:tics  at  the  platoon  level  and  below,  response 
of  vehicles  and  small  units  to  enemy  actions,  digitized  terrain,  and  modeling  of  the 
battleHeld  environment  effects  of  smoke  and  artillery  dust  SPARTA  provided  support  in 
the  modeling  of  weapons  and  associated  target  effects  in  SIMNET-D,  modeling  of  the 
human  responses  to  the  effects  of  battlefield  lasers,  and  used  ALWSIM  to  perform  force- 
on-force  simulation  and  analysis  of  DARPA  programs. 

ALWSIM  will  be  used  in  several  areas:  validation  of  phenomenology  and 
characteristics  of  the  ARWA  SS  modules,  development  of  scenarios,  investigation  of 
expanded  scenarios,  and  to  run  many  replications  to  determine  the  outcome  of  the 
scenarios. 

7.3  Specific  Validation  Activities 

7.3.1  VSM 

The  Visual  System  Module  (VSM)  will  validated,  in  conjunction  with  the  FSM  and 
aircraft  kits,  to  insure  the  visual  and  sensor  images,  moving  models,  lighting, 
environmental  scenes,  crew  station  interfaces,  and  out-the-window  displays  provide  an 
accurate  representation  of  the  scenario  being  generated  as  well  as  a  realistic  visual  effect  to 
the  pilot/co-piloL 
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Table  7.3.1  shows  the  structure  and  output  validation  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 


Phase: 

Activi^: 

■eft ,  !TJ  iTi  tn  rrrfrr— 

Documentation  and  Reviews 

V 

yi 

^Trr'nrrtm 

V 

V 

KiTTTmm’n  ffi  rtjrrr™™* 

HHHBHI 

■■■■■I 

mmmmsMEsmsmm 

i 

yl 

1  Scenario  Identification 

yi 

yj 

yl 

V 

yl 

1  Test  and  Evaluation 

yl 

Table  7.3. 1  Structure  and  Output  Validation  Activities  for  the  VSM 


7.3.2  FSM 


7. 3. 2.1  FSM  Base 

The  Flight  System  Module  (FSM)  will  validated,  in  conjunction  with  the  VSM  and 
aircraft  kits,  to  insure  the  crew  station  interfaces  (conu-ols,  switches,  alarms,  and  other 
devices)  provide  an  accurate  response  in  the  scenario  being  generated  as  well  as  a  realistic 
vi.sual  effect  to  the  pilot/co-piloL 
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Table  7.3.2. 1  shows  the  structure  and  output  validation  activities  that  are  to  be 
performed  during  each  devetopment  phase  for  this  comptmenL 


Table  7.3.2. 1  Structure  and  Chi^ut  Validation  Activities  for  the  FSM  Base 


7. 3. 2. 2  FSM  Comanche 

Table  7.3.2.2  shows  the  structure  and  output  validation  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 


Table  7.3.2.2  Structure  and  Output  Validation  Activities  for  the  FSM  Comanche 
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7. 3. 2. 3  FSM  Longbow 


Table  7. 3.2.3  shows  the  structure  and  output  validation  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 
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Table  7.3.2.3  Structure  and  Ou^ut  Validation  Activities  for  the  FSM  Longbow 


7.3.3  SSM 

7.3.3. 1  RAH-66  Comanche  Kit 

Table  7.3.3. 1  shows  tlie  structure  and  output  validation  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 
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Table  7.3.3. 1  Structure  and  Chitput  Validation  Activities  for  RAH-66  Comanche  Kit 
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7. 3. 3. 1.1  RAH>66  Flight  Controls 

The  ARWA  RAH-66  flight  controls  will  be  quantitatively  validated  against 
reference  (engineering  simulator  output)  data  to  assure  tte  validity  of  the  simulation.  The 
following  list  enumerates  tests  to  be  conducted  in  the  engineering  simulator  and  duplicated 
in  the  ARWA  RAH-66  simulator.  During  each  of  these  tests  the  appropriate  control 
position  and  applied  force  will  be  recorded.  Time  histories  and  cross  plots  of  these 
parameters  will  be  compared  with  reference  data  to  validate  the  simulation  hardware  and 
software  models.  These  tests  will  be  performed  with  applicable  trim  and  stability 
augmentation  systems  both  on  and  off  to  confirm  the  effects  of  these  systems  on  control 
forces  and  dynamic  characteristics. 

Quantitative  Flight  Control  Validation  Tests 

1)  Longitudinal  Cyclic  Control  Full  Range  Sweep  (Ground,  Static) 

2)  Lateral  Cyclic  Control  Full  Range  Sweep  (Ground,  Static) 

3)  Primary  Collective  Control  Full  Range  Sweep  (Ground,  Static) 

4)  Secondary  Collective  Control  Full  Range  Sweep  (Ground,  Static) 

5)  Pedal  Control  Full  Range  Sweep  (Ground,  Static) 

6)  Control  System  Freeplay  (Ground,  Static) 

7)  Trim  System  Rates 

8)  AFCS  Override  Forces 

9)  Control  System  Free  Re^nse  to  Step  Inputs  (Hover) 

10)  Control  System  Free  Response  to  Step  Inputs  (Cruise) 

The  validation  of  the  primary  flight  controls,  AFCS  and  Flight  Director  will  be 
supplemented  by  the  tests  to  ^  performed  in  the  flight  dynamics  validation  (see  Section 
7.3.3. 1.6).  Due  to  the  intimate  coupling  between  the  flight  controls  and  the  flight 
dynamics  many  of  the  tests  described  in  the  flight  dynamics  validation  will  also  serve  to 
validate  these  modules  simultaneously.  Secondary  controls  operation,  such  as  the  position 
vs.  force  relationship  for  the  gear  handle  operation,  will  be  validated  subjectively  during  the 
course  of  these  tests.  Tlie  effects  of  battle  damage  to  the  flight  controls  will  be  validated  by 
subjective  pilot  evaluation  substantiated  with  engineering  analysis  of  the  resultant  effects. 
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Table  7.3.3. 1.1  shows  the  structure  and  ou4)ut  validation  activities  that  are  to  be 
performed  during  each  development  phase  of  this  component 
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Table  7.3.3. 1 . 1  Structure  and  Output  Validation  Activities  for  RAH-66  Flight 

Controls 


7.3.3. 1.2  RAH-66  Nav/Comm 

HARS/AHRS.DNS.GPS 

TBD 

ICS.  VHF.UHFCQMM 

Validation  of  the  switch  settings  should  be  accomplished  as  part  of  the  Flight 
Station  Module  validation.  The  only  model  or  software  validation  should  be  of  the 
intervisibility  or  line  of  sight  computations. 

AIRJIAIA 

ValiUaliun  consists  of  checking  Uiat  the  data  reported  by  the  ADSS  equals  that 
generated  by  the  respective  segment  and  is  modified  as  necessary  due  to  changes  in  power 
statu.s,  battle  (iumage,  and  on/off  adaptability  parameter. 

AIHS. 

Validation  of  incoming  messages  will  be  accomplished  by  comparing  messages 
received  by  the  Flight  Station  segment  with  messages  that  were  received  from  the  DIS 
network.  Validation  of  outgoing  messages  will  be  accomplished  by  comparing  messages 
constructed  by  crew  member  inputs  from  the  Flight  Station  with  messages  that  are  passed 
to  the  Environment  segment  for  transmission  onto  the  DIS  network.  Messages  shall  be 
sent/received  when  radio  status  and  frequency  are  properly  set,  and  not  scnt/received  when 
radio  status  and  frequency  are  not  properly  set. 
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MOVING  MAE 

Validation  of  the  moving  map  will  be  accomplished  by  comparing  its  appearance, 
controls,  display  and  operation  with  teal  world  equipment  The  accuracy  of  ownship 
position  will  be  determined  by  comparing  the  position  as  presented  on  the  moving  map 
display  with  the  position  as  determined  by  other  navigation  systems. 


Table  7.3.3. 1.2  shows  the  structure  and  output  validation  activities  that  are  to  be 
perfoimed  during  each  development  phase  for  this  component 


KHRBHHIiH 

mTTtTTCTTm^/i.ir.rTTriTTii^ 

HIHHHi 

HIHHHi 

HHHi 

1  Documentation  and  Reviews 

yl 

■■■  tr; 

yi 

H*!  j )  1 4  iiTi  tf!  mriTTBi^RBR 

HHHi 

>1 

y/ 

yl 

yj 

yl 

1  Models 

yl 

V 

yl 

Table  7.3.3. 1 .2  Structure  and  Output  Validation  Activities  for  RAH-66  Nav/Comm 


7. 3. 3. 1.3  RAH-6d  Weapons 

Validation  of  weapon  models  will  utilize  available  validated  models  (i.e., 
ALW.SIM)  or  other  validated  data  source  (AMSAA  trajectory  data  or  plots  and  dispersion 
data )  to  insure  realistic  model  performance. 

Validate  the  realism  of  ownship  combat  damage  through  the  use  of  SMEs  and  by 
comparing  simulated  results  with  test  results.  Specifically,  assess  the  realism  of  the 
probabilities  of  kill  and  damage  that  are  computed  as  a  function  of  the  weapon  (warhead) 
and  its  detonation  location  relative  to  the  predefined  aircraft  zones. 

VULCAN  n  20mm  Gun 

Compare  flyout  and  dispersion  patterns  to  those  generated  by  model  INCURSION 
embedded  in  ALWSIM.  AMSAA  models  are  available  to  provide  additional  dispersion  and 
hit  data  for  various  targets. 

Validate  at  the  segment  level  by  testing  to  see  that  the  weapon  operates  as  follows  in 
a  realistic  manner 

-  bullets  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  gun  can  be  selected  and  armed  (master  arm) 

-  gun  correctly  positioned  (AUTO/CLOSED/LOAD/DEM.OY) 
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-  gun  can  be  taigeted  within  conect  azimuth  and  elevation  limits 

-  gun  can  be  fued  -  trigger  1st  and  2nd  detent  operation 

-  rounds  remaining  decreases  properly 

-  bullets  follow  proper  trajectory  and  impact  about  targeted  point 

-  compute  all  data  required  by  Environment  segment  for  DIS  PDUs 

Validate  the  weapon  system  at  the  device  and  simulator  system  level  by  confirming 
that  threats  and  targets  on  the  network  can  be  targeted,  engaged  and  killed/damaged. 

We  do  not  have  validated  data  for  the  VULCAN  n  20mm  gun. 

2.75-FFARMK-66 

Compare  flyout  and  dispersion  patterns  to  those  generated  by  model  INDIRECT 
FIRE  EFFECTS  embedded  in  ALWSIM.  AMSAA  models  are  available  to  provide 
additional  dispersion  and  hit  data  for  various  targets  as  well  as  limited  test  flight  data  in  plot 
format . 

Validate  at  the  segment  level  by  testing  to  see  that  the  weapon  operates  as  follows  in 
a  realistic  manner 

-  rockets  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  rockets  can  be  selected  and  armed  (master  arm) 

-  rockets  can  be  properly  targeted 

-  rockets  can  be  fired  -  trigger  1st  and  2nd  detent  operation 

-  number  remaining  decreases  properly 

-  rockets  follow  proper  trajectory  and  impact  about  targeted  poirtt 

-  compute  all  data  required  by  ^vironment  segment  for  DIS  PDUs 

Validate  the  weapon  system  at  the  device  and  simulator  system  level  by  confirming 
that  threats  and  targets  on  the  network  can  be  targeted,  engaged  and  killed/damaged. 

HYPSA70 

Compare  flyout  and  dispersion  patterns  to  those  generated  by  model  INDIRECT 
FIRE  EFFECTS  embedded  in  ALWSIM. 

Validate  at  the  segment  level  by  testing  to  see  that  the  weapon  operates  as  follows  in 
a  realistic  manner. 

-  rockets  can  be  loaded  and  tlie  number  of  rounds  is  properly  displayed 

-  rockets  can  be  selected  and  armed  (master  arm) 

-  rockets  can  be  properly  targeted 

•  rockets  can  be  fired  -  trigger  Ist  and  2nd  detent  operation 

-  number  remaining  decreases  properly 

-  rockets  follow  proper  trajectory  and  impact  about  targeted  point 

-  compute  all  data  required  by  ^vironment  segment  for  DIS  PDUs 

Validate  the  weapon  system  at  the  device  and  simulator  system  level  by  confirming 
that  threats  and  targets  on  the  network  can  be  targeted,  engaged  and  killed/damaged. 

We  do  not  have  access  to  validated  data  for  the  HYI^A  70. 

AGM-1 14A  LASER  HELLFIRE 

Use  PHI  model  in  ALWSIM  for  laser  target  acquisition  probability  comparison. 
Validate  at  the  segment  level  by  testing  to  see  that  the  weiqxm  (grates  as  follows  in 
a  realistic  manner 
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-  missiles  can  be  loaded  and  the  number  of  rounds  is  prc^ily  di^layed 

-  missiles  can  be  selected  in  (tesiied  sequence  and  aimed  (master  aim) 

-  missiles  can  be  {voperly  targeted 

•  target  must  be  within  kinematic  range  of  missile 

•  target  must  be  designated  with  cmiect  code 

-  can  be  designated  autonomously  or  remotely 

-  seeker  must  acquire  (function  of  rangeAveather,  CLOS) 

-  designated  target  within  seeker  azimuth  and  elevation  FOV  limits 

-  aircraft  launch  constraints  must  be  met 

-  indirect  fire  and  lock-<Hi-after>launch  modes 

-  missiles  can  be  fired  -  trigger  1st  and  2nd  detent  operation 

-  missiles  fire  in  selected  order 

-  number  remaining,  and  their  location,  jn'opeily  displayed 

-  missiles  follow  proper  trajectory  and  impact  target 

-  compute  all  data  required  by  Environment  segment  for  DIS  PDUs 

Validate  the  weapon  system  at  the  device  and  simulator  system  level  by  confirming 
diat  threats  and  targets  on  the  netwoik  can  be  targeted,  engaged  and  killed/damaged. 

We  have  not  identified  a  source  for  validated  LASER  HELLFIRE  trajectory  data  but 
AMS  AA  can  provide  weaptMi  test  flight  data  in  plot  fiMmat . 

Air  To  Air  Stinger  f  ATASl 

Use  FLIR90  model  in  ALWSIM  for  IR  target  acquisition,  tracking,  and  end-game 
probability  comparison.  Use  ALWSIM  for  ^neration  of  comparison  flyouts. 

V^idate  at  the  segment  level  by  testing  to  see  that  the  weapon  operates  as  follows  in 
a  realistic  manner 

-  missiles  can  be  loaded  and  the  number  of  rounds  is  prqrerly  displayed 

-  missiles  can  be  selected  in  desired  sequence  and  armed  (master  arm) 

-  missiles  can  be  properly  targeted  to  obtain  "SHOOT"  cue 

-  seeker  must  acquire  (function  of  range/weather,  CLOS,  target  IR  intensity) 

-  seeker  slaves  to  targeting  system 

-  designated  target  within  seeker  azimuth  and  elevation  FOV  limits 

-  seeker  provides  cue  for  tone 

-  missiles  can  be  fired  -  trigger  1st  and  2nd  detent  operation 

-  missiles  fire  in  selected  order 

-  number  remaining,  and  their  location,  properly  displayed 

-  missiles  follow  proper  trajectory  and  impact  target 

-  compute  all  data  required  by  Environment  segment  for  DIS  PDUs 

Validate  the  wetqran  system  at  the  device  and  simulator  system  level  by  confirming 
that  threats  and  targets  on  the  netwoik  can  be  targeted,  engaged  and  killed/damaged. 

We  have  not  identified  a  source  for  validated  ATAS  trajectory  data  but  AMSAA  can 
provide  weapon  test  flight  data  in  plot  format . 
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Table  7.3.3. 1.3  shows  the  structure  and  output  validation  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 
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Table  7.3.3. 1 .3  Stracture  and  Output  Validation  Activities  for  RAH-66  Weapons 


7. 3. 3. 1.4  RAH-06  Sensors 

The  Night  Vision  and  Electronic  Sensors  Directorate  of  AMSAA  has  been  involved 
with  the  verification  and  validation  of  sensor  displays  in  the  past  and  should  be  involved 
with  our  current  effort  Previous  sensor  display  evaluation  at  AMSAA  have  focused  on  the 
results  of  an  initiative  on  the  ACQSIM  Simulation  for  Target  Acquisition. 

The  sensor  validation  process  should  include  collection  of  CIG  display 
characteristics  and  calibration  methodologies  to  provide  CIG  metrics  for  the  simulated 
acquisition  sensors.  A  series  of  tests  would  then  be  conducted  on  the  simulator  to 
determine  the  functions  which  describe  the  deviations  between  observer  simulated  target 
response  and  the  real  world,  and  to  determine  how  great  a  departure  from  reality  can  be 
tolerated.  Additional  testing  with  trained  crewmen  to  determine  if  the  simulator  and  models 
produce  realistic  detection  and  acquisition  results  as  a  full  demo/face  validation. 

The  validation  activity  for  the  TADS  will  be  to  validate  that  the  data  used  in  the 
adaptability  parameters  accurately  represents  Uie  performance  of  the  TADS. 
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Table  7.3.3. 1.4  shows  the  structure  and  output  validation  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 
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Tabic  7.3.3. 1.4  Structure  and  Output  Validation  Activities  for  RAH-66  Sensors 


7. 3. 3.1. 5  RAH-66  ASE 

Radar  Warning  APR-39  (V)l  (V)2 
APR-48 

The  task  is  to  validate  that  if  the  Tactical  and  Natural  Environment  (TNE)  Segment 
emission  environment  contains  RF  signals  which  are  then  represented  by  protocol  data 
units  (PDUs),  then  the  APR-39  and  APR-48  would  detect,  identify,  and  generate  the 
correct  alerts. 

Validate  the  system  at  the  segment  level  by  testing  that  the  following  parameters  are 
properly  computed  in  accordance  with  the  radar  warning  adaptability  parameters;  EID  file; 
threat  emitter  type,  location,  power,  mode,  and  beam  characteristics;  and  uwnship  location 
and  orientation: 

-  equipment  functional  status  from  electric  power  indications  and  sustained  battle 

damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  the  aieas  of  tlio  equipment  and/or  sensors 

-  identification  in  accordance  with  EID  file  and  emitter  beam  parameters 

-  maximum  detection  range  and  range  estimate  from  ID,  EID  file  and  detected 

power 

-  detection/no  detection  from  maximum  range  and  threat  and  ownship  locations 

-  coarse  radar  site  list  for  radar  warning  receiver  and  radar  jammer  operation 

-  emitter  mode  (search,  acquisition,  track,  or  missile  activity)  from  EID  file  and 

emitter  beam  characteristics  and  activity 

-  emitter  relative  bearing  from  AOA  information  and  ownship  heading 

-  emitter  priority  based  on  priority  in  EID  file,  detecting  equipment  and  range 
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-  emitter  location  based  on  range  and  bearing 

-  emitter  locatitm  based  on  triangulation  processing  by  multiple  team  members 

-  radar  warning  indications  (up  to  8  visual  effects  and  up  to  5  visual  effects), 

prioritized  target  list  and  other  interface  parameters  comput«l  and  passed 

-  detection  characteristics  can  be  modified  within  the  limits  of  the  radar  warning 

adaptability  parameters 

Validate  the  system  at  the  device  and  simulator  system  level  by  confirming  that  it 
will  detect  threats  that  are  on  the  network  and  cause  the  appropriate  warnings  to  be 
activated 

NEEDED:  APR-39  (V)l  (V)2,  APR-48  performance  description. 

Radar  Jammer  al(^136  (V)i/5 

The  task  is  to  validate  that  the  radar  jammer  outputs  defined  in  the  PDU  accurately 
depict  the  signals  that  would  jam  the  radars  detected  by  the  RWR. 

Validate  the  system  at  the  segment  level  by  testing  that  the  following  parameters  are 
properly  computed  in  accordance  with  the  radar  jammer  adaptability  parameters;  EID  file  ; 
course  radar  site  list;  and  ownship  location  and  orientation: 

-  equipment  functional  status  from  electric  power  indications,  ECM  enable  status 

and  sustained  battle  damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  the  areas  of  the  equipment  and/or  antennas 

-  emitter  detected  if  on  course  radar  site  list  generated  by  radar  warning  receiver 

-  emitter  prioritized  in  accordance  with  EE)  file  and  range  between  emitter  site 

location  and  ownship  location 

-  AOA  evaluations  using  ownship  angular  position  values,  actual  earth  axis  azimuth 

and  elevation  to  the  emitter,  and  EE)  file  error  indications 

-  radar  jamming  parameters  using  results  of  the  AOA  evaluations,  the  RF  emitter's 

beam  parameters  and  the  EE)  file  jamming  indications 

-  RF  jamming  characteristics  required  to  effectively  simulate  tlie  jamming  of  the 

selected  emitters  (up  to  10)  and  other  interface  parameters  computed  and 
passed 

-jamming  characteristics  can  be  modified  within  tire  limits  of  the  ladai’ jammer 
adaptability  parameters 

Validate  the  system  at  the  device  and  simulator  system  level  by  confirming  that  it 
will  realistically  jam  RF  threats  that  are  on  the  network. 

NEEDED:  AL(3-136  (V)l/5  performance  description. 

Lassr..Waniin8  avr-2(V)tbd 

The  task  is  to  validate  that  if  the  Tactical  and  Natural  Environment  (TNE)  Segment 
emission  environment  contains  laser  signals,  then  the  AVR-2  would  detect,  identify,  and 
generate  the  correct  alerts. 

Validate  the  system  at  the  segment  level  by  testing  that  the  following  parameters  are 
properly  computed  in  accordance  with  the  laser  warning  adaptability  parameters;  laser  E) 
file;  laser  type,  location,  power,  code,  and  beam  characteristics;  and  ownship  location  and 
orientation: 
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-  equipment  functional  status  from  electric  power  indications  and  sustained  battle 

damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  the  areas  of  the  equipment  and/or  sensors 

-  identification  in  accordance  with  la^  ID  file  and  laser  beam  parameters 

-  maximum  detection  range  and  range  estimate  from  ID,  laser  ID  file  and  detected 

power 

-  detection/no  detection  from  maximum  range  and  laser  and  ownship  locations 

-  laser  code  from  laser  ID  file  and  laser  beam  characteristics 

-  laser  relative  bearing  from  AOA  information  and  ownship  heading 

-  laser  priority  based  on  priority  in  laser  ID  file  and  range 

-  emitter  location  based  on  range  and  bearing 

-  emitter  location  based  on  triangulation  processing  by  multiple  team  members 

-  laser  warning  indications  (up  to  TBD  visual  effects  and  up  to  TBD  visual  effects), 

prioritized  target  list  and  other  interface  parameters  computed  and  passed 

-  detection  characteristics  can  be  modified  within  the  limits  of  the  IR  warning 

adtqitability  parameters 

Validate  the  system  at  the  device  and  simulator  system  level  by  confirming  that  it 
will  detect  threats  that  are  on  the  network  and  cause  the  appropriate  warnings  to  be 
activated. 

NEEDED:  AVR-2  (V)  performance  descriptitm. 

IBJammet  alq-144  (V)i/3 

The  task  is  to  validate  that  the  IR  jammer  outputs  defined  in  the  PDU  accurately 
depict  the  signals  that  would  jam  IR  sensors. 

Validate  the  system  at  the  segment  level  by  testing  that  the  following  parameters  are 
properly  computed  in  accordance  with  the  IR  jammer  adaptability  parameters;  IR  jammer 
characteristics;  location  of  IR  seeker;  and  ownsiiip  location: 

-  equipment  functional  status  from  electric  power  indk  'ions,  ECM  enable  status 
and  sustained  battle  damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  esult  of  sustained  battle 
damage  in  tlie  aicas  of  the  equipment  and/or  IR  element 

-  IR  jamming  parameters  for  simulation  of  the  cooldown  and  warmup  cycling 
technique 

-  IR  jamming  characteristics  and  other  interface  parameters  computed  and  passed 
-jamming  characteristics  can  be  moditied  within  the  limits  of  the  IR  jammer 
adaptability  parameters 

Validate  the  system  at  the  device  and  simulator  system  level  by  confirming  that  it 
will  realistically  jam  IR  threats  that  are  on  the  iKtwork. 

NEEDED:  ALQ-144  (V)l/3  performance  description. 

Radiation  Warning  RWS 

The  task  is  to  validate  that  if  the  Tactical  and  Natural  Environment  (TNE)  Segment 
emission  environment  contains  radiation  effects,  then  the  RWS  would  detect,  identify,  and 
generate  the  correct  alerts. 
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Validate  the  system  at  the  segment  level  by  testing  that  die  following  parameters  are 
properly  computed  in  accordance  with  the  radiation  warning  adaptability  parameters; 
radiological  ID  file;  radiation  type,  location,  source  intensi^;  and  own^p  location: 

-  equipment  functional  status  from  electric  power  indications  and  sustained  battle 

damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  batde 

damage  in  the  areas  of  the  equipment  and/or  sensor 

-  detectable/not  detectable  from  radiation  type 

-  intensity  level  at  ownship  from  source  intensity  and  range  between  radiation 

source  location  and  ownship  location 

-  detection/no  detection  from  radiation  ID  file  detection  threshold  and  radiation 

intensity  level  at  ownship 

-  radiological  alert  indication  and  odier  interface  parameters  computed  and  passed 

-  detection  characteristics  can  be  modified  within  the  limits  of  the  radiation  warning 

adaptability  parameter 

Validate  the  system  at  the  device  and  simulator  system  level  by  confirming  that  it 
will  detect  radiation  that  is  simulated  on  the  network  and  cause  the  appropriate  warnings  to 
be  activated. 

NEEDED:  RWS  perfcmnance  description. 

Chemical  Warning  CWS 

The  task  is  to  validate  that  if  the  Tactical  and  Natural  Environment  (TNE)  Segment 
emission  environment  contains  chemical  agents,  then  the  CWS  would  detect,  identify,  and 
generate  the  correct  alerts. 

Validate  the  system  at  the  segment  level  by  testing  that  the  following  parameters  are 
properly  computed  in  accordance  with  the  chemical  warning  adaptability  parameters; 
chemical  ID  ^e;  chemical  type,  cloud  center  location,  cloud  radius,  cloud  density;  and 
ownship  location: 

-  equipment  functional  status  from  electric  power  indications  and  sustained  battle 

damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  die  aieas  of  die  equipment  and/oi  sensei 

-  detectable/not  detectable  from  chemical  type 

-  ownship  within/not  within  chemical  cloud  based  on  cloud  radius,  cloud  center 

location  and  ownship  location 

-  detectiun/no  detection  from  cliemicai  ID  file  detection  threshold  and  chemical 

density  level  at  ownship 

-  chemical  alert  indication  and  other  interface  parameters  computed  and  passed 

-  detection  characteristics  can  be  modified  within  the  limits  of  the  chemical  warning 

adaptability  parameters 

Validate  the  system  at  the  device  and  simulator  system  level  by  confirming  that  it 
will  detect  chemical  clouds  that  are  simulated  on  the  network  and  cause  the  appropriate 
warnings  to  be  activated. 

NEEDED:  CWS  performance  description. 
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Table  7.3.3.  LS  shows  the  structure  and  ouq)ut  validation  activities  that  are  to  be 
peifcmned  during  each  development  phase  for  this  compcmenL 
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Table  7.3.3. 1.5  Structure  and  Output  Validation  Activities  for  RAH-66  ASE 


7. 3. 3. 1.6  RAH-66  Flight  Dynamics 

The  ARWA  RAH-66  flight  dynamics  will  be  quantitatively  validated  against 
reference  (engineering  simulator  output)  data  to  assure  the  validity  of  the  simulation.  The 
following  tables  enumerate  tests  to  be  conducted  in  the  engineering  simulator  and 
duplicated  in  the  ARWA  RAH-66  simulator.  During  each  of  these  tests  the  appropriate 
control  positions,  pilot  applied  forces,  propulsion  parameters  and  aircraft  state  variables 
will  be  recorded.  Time  histories  and  cro.ss  plots  of  these  parameters  will  he  compared  witli 
reference  data  to  validate  the  simulation  hardware  and  software  models.  These  tests  will  be 
performed  over  a  representative  range  of  flight  conditions  covering  the  aircraft  operating 
envelope  and  with  each  applicable  aircraft  configuration  to  confirm  the  effects  on  the 
aircraft  flight  dynamics.  The  tests  will  be  repeated  with  stability  augmentation  on  and  off  to 
demonstrate  the  appropriate  effects. 

Quantitative  Performance  Validation  Tests 

1)  One  Engine  Inoperative  Takeoff  Performance 

2)  Hover  Performance  (IGE,  OGE) 

3)  Normal  Climb  Performance 

4)  Engine  Out  Climb  Performance 

5)  Cruise  Performance 

6)  Normal  Descent  Perfonnance 

Quantitative  Handling  Qualities  Validation  Tests 

1)  Low  Speed  Translational  Flight  (Forward,  Aft,  Left,  Right) 


- 118- 


ADST/TR  94-003282 


April  15,  1994 


2)  Critical  Azimiith  Stationary  (fover 

3)  Control  Response  in  Hover  (Long.,  Lateral,  Directional,  Vertical) 

4)  Longitudinal  Contrd  Re^KHise  to  Step  In{mts 

5)  LtHigitudinal  Static  Stability 

6)  Longitudinal  Dynamic  StakUty,  Long  Term 

7)  Longitudinal  Dynamic  Stability.  Short  Term 

8)  Longitudinal  Maneuvering  Sudnlity 

9)  Lateral  Response  to  Step  Inputs 

10)  Directional  Response  to  Step  Inputs 

1 1)  Directimial  Static  Stability 

12)  Laieral/Direction  Dynamic  Stability 

13)  Spiral  Stability 

14)  Alverse/Proverse  Yaw 

15)  Vertical  Response  to  Primary  Collective  Step  Inputs 

16)  Vertical  Resptmse  to  Secondary  Collective  Step  Inputs 

The  quantitative  evaluation  of  the  flight  dynamics  will  be  suj^lemented  with  a 
subjective  evaluation  of  the  ARWA  RAH-66  simulator  handling  qualities.  In  this  phase  of 
the  evaluation  it  is  a  fundamental  requirement  to  utilize  pilots  who  are  intimately  familiar 
with  the  RAH-66  flight  dynamics  and  performance.  Access  to  the  engineering  simulator 
will  be  provided  to  the  evaluation  pilots  prior  to  and  during  this  assessment  The  use  of  at 
least  3  qualifled  pilots  will  insure  a  thorough  and  accurate  evaluation  of  the  simulator.  The 
following  table  lists  the  flight  operations  to  be  performed  during  the  subjective  evaluation. 
Tests  in  which  flight  director  guidance  is  applicable  will  be  duplicated  using  the  flight 
director  engaged  and  utilized  as  the  primary  reference. 

During  the  handling  qualities  assessment  each  of  the  following  criteria  will  be 
addressed:  a)  aircraft  stability,  b)  aircraft  controllability,  c)  pilot  workload,  d)  precision  of 
task,  e)  rq)ptoptiateness  of  control  inputs  and  0  correlation  of  visual,  aural  and  motitm  cues 
to  flight  condition.  The  pilots  will  check  that  the  ARV/A  RAH-66  simulator  reproduces 
fidelity  of  flight  opcration.s  to  a  level  which  will  closely  resemble  that  of  the  engineering 
simulator  and  which  will  not  cause  eitlier  disUacUon  of  Uic  pilot  or  an  increase  or  decrease 
in  the  performance  of  the  air  vehicle  to  an  extent  that  would  affect  combat  effectiveness  or 
associated  test  results. 

Handling  Qualities  Assessment  Tests 

1)  Hovering  Toms  With  Wind 

2)  Rejecteti  I'akeoff 

3)  Atorted  Landing 

4)  Nap  of  the  Earth  Flight  Over  Terrain 

5)  Ground  Target  Tracking 

6)  Ground  Attack  Weapon  Delivery 

7)  Ground  To  Air  Weapon  Avoidance 

8)  Air  Target  Tracking 

9)  Air  to  Air  Combat  Maneuvering 
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10)  Air  to  Air  Weapon  Rriog 

1 1)  Air  to  Air  Weapon  Avoktanoe 

12)  FUgltt  with  Selected  Oxnbinatitxis  of  Ordinance  bstall^ 

13)  Fli^t  With  Selected  Pn^wlskm  System  Battle  Damage 

14)  Fli^tMdi  Selected  Fli^Contnd  Battle  Damage 

15)  Flight  With  Selected  AFCS  Battle  Damage 

16)  Fligitt  With  Selected  Airframe  Battle  Damage 

The  effects  of  battle  damage  to  the  flight  controls  will  be  validated  by  subjective 
pilot  evaluati<m  substantiated  with  engineering  analysis  of  die  resultant  effects. 

Table  7.3.3. 1.6  shows  the  structure  and  output  validation  activities  that  are  to  be 
performed  during  each  develoinnent  phase  for  this  compcmenL 
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Table  7.3.3. 1.6  Structure  and  Output  Validation  Activities  for  RAH-66  Flight 

Dynunics 


7.3.3. 1.7  RA1I>66  Propulsion 

The  ARV.'A  RAH-66  engine  and  propulsion  <;ystem  will  be  quantitatively  validated 
against  reference  (engine  deck  and  engineering  simulator  output)  data  to  assure  the  validity 
of  the  simulation.  Hie  following  list  enumerates  tests  to  be  conducted  and  duplicaied  in  the 
ARWA  RAH-66  simulator.  During  each  of  these  tests  the  appropriate  engine  and 
propulsion  system  parameters  (Gas  generator  speed.  Power  turbine  speed.  Fuel  flow. 
Engine  torque.  Turbine  gas  temperature.  Engine  oil  pressure  and  temperature.  Main  rotor 
speed  and  Tail  rotor  ^lecd)  will  be  recorded.  Time  histories  and  cross  plots  of  these 
parameters  will  be  compared  with  reference  data  to  validate  the  simulation  software  models. 
These  tests  will  be  performed  at  applicable  temperatures,  airspeeds  and  altitudes  to  include 
the  operating  envelope  of  the  RAH-66. 

Quantitative  Engine  and  Propulsion  System  Validation  Tests 
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1)  Ri4)id  Ei^gsne  Accelerations 

2)  Rt^  Eitgine  Deceleratiais 

3)  Ncnninal  Rate  Engine  Accelerations 

4)  Nmninal  Rate  Engine  Decelerations 

5)  Steady  State  Engine  Operatic 

6)  Powo- Turbine  Trim  Speed  Change  Reqprmse 

7)  Engine  and  Rotor  Spec^  Governing  Deintmstration 

The  validation  of  the  engine  and  {ffopulsion  system  may  be  sui^lemented  by  the 
tests  to  be  performed  in  the  flight  dynamics  validation  (see  Section  7.3.3.1.6)  depending 
upon  the  model  design  and  complexity.  Due  to  the  intimate  coupling  between  the 
propulsion  system  and  the  flight  dynamics  many  of  the  tests  described  in  the  flight 
dynamics  validation  may  also  serve  to  validate  these  modules  simultaneously.  The  effects 
of  battle  damage  to  the  propulsion  system  may  also  be  validated  by  subjective  evaluation 
substantiated  willi  engineering  analysis  of  the  resultant  effects. 

Table  7.3.3. 1.7  shows  the  structure  and  output  validation  activities  that  may  be 
performed  during  each  development  phase  of  this  component. 
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Table  7.3.3. 1 .7  Structure  and  Ou^ut  Validation  Activities  for  RAH-66  Propulsion 


7. 3. 3. 1.8  KAH>66  Physical  Cues 

Validation  will  consist  of  the  insuring  proper  sensory  cues  are  provided  for  the 
varied  environmental  effects  available  in  each  test 
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Table  7.3.3.1.8  shows  the  tfnictore  and  output  validation  activities  that  are  to  be 
perfoimed  during  each  develqxnent  phase  for  this  component 


Phase: 

Activity: 

Pre-PDR 

PDR-CDR 

Post-CDR 
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Structure  Validation 
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Table  7.3.3. 1 .8  Structure  and  Ou^ut  Validation  Activities  for  RAH-66  Physical 

Cues 


7.3.3. 1.9  RAH-66  TNE 

The  Tactical  and  Natural  Environment  segment  will  receive  special  attention  for, 
through  it,  the  ARWA  SS  interfaces  with  the  rest  of  the  Multiple  Simulator  Environment 
(MSE).  And  since  these  data  then  flow  to  and  from  the  other  segments  of  the  RAH-66 
Simulator  System  Module,  in  order  to  interact  with/stimulate  their  models,  the  proper 
implementation  and  functioning  of  the  TNE  segment  is  crucial  to  the  proper  functioning  of 
the  entire  RAH-66  Simulator  System  Module.  Validation  at  the  segment  level  will  require 
tests  of  the  following  area.s  to  verify  that  the  functions  operate  properly: 

TNE  Segment  Sunoort  Funcrion 

-  Executive  Control  support  service  which  provides  operational  control  for  Uie  TNE 

segment 

-  Initiali/aiion  support  service  which  controls  initial  htudware  and  software  stales 

for  the  TNE  segment 

-  ARWA  SS  Inter-Segment  Communication  support  service  which  provides  the 
TNE  segment  interface  through  the  ARWA  SS  architecture 

Atmosphere  Function 

-  Provides  ambient  atmospheric  data  as  a  function  of  altitude 

-  Provides  the  specific  atmospheric  model 

-  Provides  commanded  atmospheric  effects  such  as  wind  and  turbulence 
Database  Management  Function 
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-  Provides  control  of  the  ARWA  SS  databases  before,  and  during,  a  real-time 

experiment  This  function  shall: 

-  filter  out  those  entities  which  are  beyond  a  specified  range  in  order  to 

reduce  the  scope  of  actively  modeled  entities 

-  process  logical  and  data  faults  around  the  gaming  areas 

-  provide  the  management  of  dynamic  database  elements,  as  a  minimum,  the 

location  of  platform  entity  crash  ^tes 

-  maintain  a  list  of  the  terrain  and  culture  points  within  the  gaming  area  that 

have  been  damaged,  or  otherwise  affected,  in  an  experiment 

-  the  reference  database  provides  the  background  terrain  and  culture 

definition  required  for  resolution  of  spatial  relations,  occulting,  etc. 
Spatial  Relations  Function 

-  Provides  models  that  characterize  the  relationship  between  a  vehicle  and  elements 
of  the  natural  and  tactical  environment  This  function  will: 

-  determine  the  slant  range  from  a  specified  entiQr  to  natural  and  tactical 

entities  in  the  gaming  area 

-  calculate  height  above  terrain,  for  a  specified  entity,  based  upon  the  terrain 

characteristics  contained  in  the  terrain  database 

-  detect  the  occurrence  of  collisions  between  a  specified  entity  and  entities  or 

terrain  with  which  it  can  collide 


Occulting  Function 

-  Determines  the  line-of  -sight  continuity  between  any  object  or  designated  area  and 

the  ownship,  or  for  other  objects  in  the  simulation 
Qwnship  Weapons*  Damage  Assessment  Function 

-  Provides  damage  data  for  each  simulated  ownship  weapon  fired  during  a  real-time 

experiment 

Entity  Management  Function 

-  Simulates  the  physical  characteristics  of  all  active  platforms  in  a  real-time 

experiment 

ii  shall  use  the  sqipropriate  dead  reckoning  algorithms,  as  defmed  by  the 
MSE  for  each  entity  generated  by  the  MSE.  to  update  their  position 
and  attitude  between  update  messages 

-  it  shall  integrate  the  updated  information  about  the  entity  state  in  order  to 

produce  a  seamless  simulation  of  tire  entity  within  the  ownship 
Entity  Database  function 

-  Provides  an  extensive  and  detailed  description  of  the  non-ownship  entities  that 

may  be  active  in  an  experiment.  It  .sliall  also  provide  for  the  generation 
and  maintenance  of  the  entity  data. 

Entity  Weapons  Function 

-  Simulates  the  firing  and  flight  track  of  weapons  detectable  to  the  ownship  during  a 

real-time  experiment.  It  shall; 

-  activate,  fly  and  deactivate  weapons  in  accordance  with  instructions  from 

the  Entity  Management  function 

-  model  all  of  the  control  and  operation  parameters  for  weapon  entities, 

based  on  control  requests 
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•  accefHcomnuuid,  cimtrol  and  poaitira  infonnation  from  the  MSE 
Interaction  function  dealing  we^tons  ^riiich  are  created  and 
controlled  by  other  simulators  in  the  MSE 

-  integrate  this  infonnatioa  into  a  seamless  ^ulation  of  weapon  entities 

-  model  die  flight  path  fidelity  of  weapon  entities 

-  model  the  mass  {uopeities  of  wei^n  entities 
Entity  Expendable  Countemieasiire  Function 

-  Simulates  deployment  of  expendable  countermeasures  (e.g.  chaff  and  flares)  firom 

non-ownstiip  platforms  during  a  experiment  Expendable 
countermeasures  dispensing  will  be  controlled  by  other  simulators. 

MSE  Interaction  Function 

-  Provides  the  communication  protocol  and  data  formats  required  for  interaction 

between  the  TNE  segment  and  the  MSE. 

-  The  MSE  interaction  function  shall  provide  all  formatting,  conversion,  and  com¬ 

munication  required  for  the  TNE  segment  to  communicate  within  the  MSE 

-  Communicailuiis  shall  use  the  DIS  protocol 

-  Communicatitms  between  simulators  in  the  MSE  shall  occur  via  DIS  LAN. 

Validation  of  the  TNE  segment  at  the  device  and  simulator  system/MSE  level  will 
require  tests  of  the  following  areas  to  verify  tha  the  functions  operate  properly: 

-  Create  a  scenario  with  one,  then  multiple,  ownships,  terrain,  threats,  targets  and 

other  tactical  elements.  Cause  elements  of  the  tactical  threat  environment  to 
take  actions  that  will  provide  stimuli  for  all  RAH-66  weapon  systems. 

-  Employ  all  ownship  sensors  to  detect  threats  and  targets.  Confirm  that  the 

sensors  operate  realistically. 

-  Employ  all  ASE  systems  to  detect  threats  and  to  defeat  them  through  RF  and  IR 

jamming  and  the  employment  of  chaff  and  flares.  Confirm  that  the  ASE 
systems  operate  realistically. 

-  Target  both  air  and  ground  targets  and  employ  all  air-to-air  and  air-to-ground 

weapons  against  them.  Confirm  that  all  RAH-66  weapon  systems  can  kill 
or  damage  and  that  they  operate  realistically. 

-  Employ  all  nav/com  systems  and  confirm  that  they  operate  reali.stically. 

-  Confirm  that  the  visuals  are  present  and  ate  updated  smoothly. 

-  Confirm  all  special  effects  and  physical  cues  arc  presented  in  a  realistic  manner. 

-  Confirm  that  ail  controls  and  displays  operate  in  a  realistic  manner. 

-  When  ownship  receives  fitc,  cotifinu  that  damage  leccived  is  realistic. 
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Table  7.3.3. 1.9  shows  the  structure  and  output  validation  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 
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Table  7.3.3. 1 .9  Structure  and  Chitput  Validation  Activities  for  RAH-66  TNE 


7. 3. 3. 2  AH-64D  Longbow  Kit 

Table  7.3.3.2  shows  the  structure  and  output  validation  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 
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Pre-tDR 

Structure  Validation 

Documentation  and  Reviews 

V 

V 

SW  Architecture  Assessment 

V 
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Scenario  Identification 

V 

V 

V 

v 

V 

Test  and  Evaluation 

V 

Table  7.3.3.2  Structure  and  Output  Validation  Activities  for  AH-64D  Longbow  Kit 


7.3.3.2. 1  AH-64D  Flight  Controls 

The  ARWA  AH-64D  flight  controls  will  be  quantitatively  validated  against 
reference  (flight  test)  data  to  assure  the  validity  of  the  simulation.  The  following  list 
enumerates  tests  to  be  conducted  in  flight  test  and  duplicated  in  the  ARWA  AH-64D 
simulator.  During  each  of  these  tests  the  appropriate  control  position  and  applied  force  will 
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be  recorded.  Time  histories  and  cross  plots  of  these  parameters  will  be  compared  with 
reference  data  to  validate  the  simulatitm  hardware  and  software  models.  These  tests  will  be 
performed  with  applicable  trim  and  stability  augmentation  systems  both  on  and  off  to 
ctmfirm  the  effects  of  these  systems  on  ctmtrol  forces  and  dynamic  characteristics. 

Quantitative  Flight  Control  Validation  Tests 

1)  Longitudinal  Cyclic  Control  Full  Range  Sweep  (Static) 

2)  Lateral  Cyclic  Control  Full  Range  Sweep  (Static) 

3)  Primary  Collective  Control  Full  Range  Sweep  (Static) 

4)  Pedal  Control  Full  Range  Sw^p  (Static) 

5)  Control  System  Freeplay  (Static) 

6)  Trim  System  Rates 

7)  AFCS  Override  Forces 

8)  Control  System  Free  Response  to  Step  Inputs  (Hover) 

9)  Control  System  Free  Response  to  Step  Inputs  (Cruise) 

The  validation  of  the  primary  flight  controls,  AFCS  and  Flight  Director  will  be 
supplemented  by  the  tests  to  be  performed  in  the  flight  dynamics  validation  (see  Section 
7.3.3.2.6).  Due  to  the  intimate  coupling  between  the  flight  controls  and  the  flight 
dynamics  many  of  the  tests  described  in  the  flight  dynamics  validation  will  also  serve  to 
validate  these  modules  simultaneously.  Secondary  controls  operation,  such  as  the  position 
vs.  force  relationship  for  the  gear  handle  operation,  will  be  validated  subjectively  during  the 
course  of  these  tests.  The  effects  of  battle  damage  to  the  flight  controls  will  be  validated  by 
subjective  pilot  evaluation  substantiated  with  engineering  analysis  of  the  resultant  effects. 

Tabic  7.3.3.2.1  shows  the  structure  and  output  validation  activities  that  arc  to  be 
performed  during  each  development  phase  of  this  component 


Phase: 

Activity: 

Structure  Validation 

Documentation  and  Reviews 

V 

V 

Real  World  Comparisons 

mammm 

V 

Face  Validation 

V 

Output  Validation 

V 

V 

Data  Collection 

V 

Scenario  Identification 

V 

V 

V 

V 

V 

Table  1.33.2. 1  Structure  and  Output  Validation  Activities  for  AH-64D  Flight 

Controls 
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7.3.3.2.2  AH-64DNav/C(Mnm 

INU.  DVRS.  GPS 
TBD 

ICS.  VHF.UHF  COMM 

Validation  of  the  switch  settings  should  be  accomplished  as  part  of  the  Flight 
Station  Module  validation.  The  only  model  or  software  validation  should  be  of  the 
intervisibility  or  line  of  sight  computations. 

AIRDATA 

Validation  consists  of  checking  that  the  data  reported  by  the  ADSS  equals  that 
generated  by  the  respective  segment  and  is  modified  as  necessary  due  to  changes  in  power 
status,  battle  damage,  and  on/off  adaptability  parameter. 

IMPROVED  DATA  MODEM  ODMl 

Validation  of  incoming  messages  will  be  accomplished  by  comparing  messages 
received  by  the  Flight  Station  segment  with  messages  that  were  received  from  the  OIS 
netwoik.  Validation  of  outgoing  messages  will  be  accomplished  by  comparing  messages 
constructed  by  crew  member  inputs  from  the  Flight  Station  with  messages  that  are  passed 
to  the  Environment  segment  for  transmission  onto  the  DIS  network.  Messages  shall  be 
sent/received  when  radio  status  and  frequency  are  properly  set,  and  not  sent/received  when 
radio  status  and  frequency  are  not  properly  set. 

Table  7.3.3.2.2  shows  the  stnicture  and  output  validation  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 


Phase: 

Activity: 

i^re-FOR 

Structure  Validation 

Documentation  and  Reviews 

Real  World  Comparisons 

V 

SW  Architecture  Assessment 

V 

V 

Output  Validation 

V 

Data  Collection 

yl 

< 

Scenario  Identification 

V 

V 

Models 

V 

msiHH 

mm\  ni  1 

V 

Table  7.3.3.2.2 
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7.3.3.2.3  AH-64D  Weapons 

Validation  of  weapon  models  will  utilize  available  validated  models  (i.e., 
ALWSIM)  or  other  validated  data  source  (AMSAA  trajectory  plots  and  dispersion  data )  to 
insure  realistic  model  performance.. 

Validate  the  realism  of  ownship  combat  damage  through  the  use  of  SMEs  and  by 
comparing  simulated  results  with  test  results.  Specifically,  assess  the  realism  of  the 
probabilities  of  kill  and  damage  that  are  computed  as  a  function  of  the  weapon  (warhead) 
and  its  detonation  location  relative  to  the  prectefined  aircraft  zones. 

M-230E1  30mm  Gun 

Compare  flyout  and  dispersion  patterns  to  those  generated  by  model  INCURSION 
embedded  in  ALWSIM.  AMSAA  models  are  available  to  provide  additional  dispersion  and 
hit  data  for  various  targets. 

Validate  at  the  segment  level  by  testing  to  see  that  the  weapon  operates  as  follows  in 
a  realistic  manner: 

-  bullets  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  gun  can  be  selected  and  armed  (master  arm) 

-  gun  correctly  positioned  (AUTO/CLOSED/LOAD/DEPLOY) 

-  gun  can  be  targeted  within  correct  azimuth  and  elevation  limits 

•  gun  can  be  fired  •  trigger  1st  and  2nd  detent  operation 

'  rounds  remaining  decreases  properly 

-  bullets  follow  proper  trajectory  and  impact  about  targeted  point 

-  compute  dl  data  required  by  Environment  segment  for  DIS  PDUs 

Validate  the  weapon  system  at  the  device  and  simulator  system  level  by  confirming 
that  threats  and  targets  on  the  network  can  be  targeted,  engaged  and  killed/damaged. 

2.75"  FFARMK-66 

Compare  flyout  and  dispersion  patterns  to  those  generated  by  model  INDIRECT 
FIRE  EFFECTS  embedded  in  ALWSIM.  AMSAA  models  are  available  to  provide 
additional  dispersion  and  hit  data  for  various  iaigets  as  well  as  limited  test  flight  data  in  plot 
format . 

Validate  at  the  segment  level  by  testing  to  see  that  the  weapon  operates  as  follows  in 
a  realistic  manner: 

-  rockets  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  rockets  can  be  selected  and  armed  (master  arm) 

-  rockets  can  be  properly  targeted 

-  rockets  can  be  fired  -  trigger  1st  and  2nd  detent  operation 

-  number  remaining  decreases  properly 

-  rockets  follow  proper  trajectory  and  impact  about  targeted  point 

-  compute  all  data  required  by  Environment  segment  for  DIS  PDUs 

Validate  the  weapon  system  at  the  device  and  simulator  system  level  by  confirming 
that  threats  and  targets  on  the  network  can  be  targeted,  engaged  and  killed/damaged. 
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AGM-114A  LASER  HELLFIRK 

Use  PHI  model  in  ALWSIM  for  laser  target  acquisition  probability  comparison. 
Validate  at  the  segment  level  by  testing  to  see  that  the  weapon  operates  as  follows  in 
a  realistic  manner 

-  missiles  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  missiles  can  be  selected  in  desired  sequence  and  armed  (master  arm) 

-  missiles  can  be  properly  targeted 

-  target  must  be  within  kinematic  range  of  missile 

-  target  must  be  designated  with  correct  code 

-  can  be  designated  autonomously  or  remotely 

-  seeker  must  acquire  (function  of  range/weather,  CLOS) 

-  designated  target  within  seeker  azimuth  and  elevation  FOV  limits 

-  aircraft  launch  constraints  must  be  met 

-  indirect  fire  and  lock-on-after-launch  modes 

-  missiles  can  be  fired  -  trigger  1st  and  2nd  detent  operation 

-  missiles  fire  in  selected  order 

-  number  remaining,  and  their  location,  properly  displayed 

-  missiles  follow  proper  trajectory  and  impact  target 

-  compute  all  data  requited  by  Environment  segment  for  DIS  PDUs 

Validate  the  weapon  system  at  the  device  and  simulator  system  level  by  confirming 
that  threats  and  targets  on  the  network  can  be  targeted,  engaged  and  killed/damaged. 

We  have  not  identified  a  source  for  validated  LASER  HELLFIRE  trajectory  data  but 
AMS AA  can  provide  weapon  test  flight  data  in  plot  format . 

AGM=I14FRF  HELLFIRE 

Use  ACQUIRE  model  in  ALWSIM  for  radar  acquisition,  tracking  performance, 
and  probability  comparison.  Use  ALWSIM  for  generation  of  HELLFIRE  comparison 
flyouts. 

Validate  at  the  segment  level  by  testing  to  see  that  the  weapon  operates  as  follows  in 
a  realistic  manner 

-  missiles  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  missiles  can  be  selected  in  desired  sequence  and  armed  (master  arm) 

-  missiles  can  be  properly  targeted 

-  target  must  be  within  kinematic  range  of  missile 

-  target  must  be  illuminate  with  correct  code 

-  can  be  designated  autonomously  or  remotely 

-  seeker  must  acquire  (function  of  range/weather,  CLOS) 

-  designated  target  within  seeker  azimuth  and  elevation  FOV  limits 

-  aircraft  launch  constraints  must  be  met 

-  indirect  fire  and  lock-on-after-launch  modes 

-  missiles  can  be  fired  -  trigger  1st  and  2nd  detent  operation 

-  missiles  fire  in  selected  order 

-  number  remaining,  and  their  location,  properly  displayed 

-  missiles  follow  proper  trajectory  and  impact  target 

-  compute  all  data  required  by  Environment  segment  for  DIS  PDUs 
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Validate  the  wetqwn  system  at  the  device  and  simulator  s^tem  level  by  confiiminig 
that  threats  and  targets  on  the  network  can  be  targeted,  engaged  and  killed/damaged. 

We  have  not  identified  a  source  for  validated  RF  HELLFIRE  trajectory  data  but 
AMSAA  can  provide  weapon  test  flight  data  in  plot  fcrnnat . 

AGM-IHKRF  HELLFIRE  II 

Use  ACQUIRE  model  in  ALWSIM  for  radar  acquisition,  tracking  performance, 
and  probability  comparison.  Use  ALWSIM  for  generation  of  HELLFIRE  comparison 
flyouts. 

Validate  at  the  segment  level  by  testing  to  see  that  the  weapon  operates  as  follows  in 
a  realistic  manner 

-  missiles  can  be  loaded  and  the  number  of  rounds  is  properly  displayed 

-  missiles  can  be  selected  in  desired  sequence  and  armed  (master  arm) 

-  missiles  can  be  properly  targeted 

-  target  must  be  within  kinematic  range  of  missile 

-  target  must  be  illuminated  with  correct  code 

-  can  be  designated  autonomously  or  remotely 

-  seeker  must  acquire  (function  of  range/weather,  CLOS) 

-  designated  target  within  seeker  aamuth  and  elevation  FOV  limits 

-  aircraft  launch  constraints  must  be  met 

-  indirect  fire  and  lock-on-after-launch  modes 

-  missiles  can  be  fired  -  trigger  1st  and  2nd  detent  operation 

-  missiles  fire  in  selected  order 

-  number  remaining,  and  their  location,  properly  displayed 

-  missiles  follow  proper  trajectory  and  impact  target 

-  compute  all  data  required  by  Environment  segment  for  DIS  PDUs 

Validate  the  weapon  system  at  the  device  and  simulator  system  level  by  confirming 
that  threats  and  targets  on  the  network  can  be  targeted,  engaged  and  killed/damaged. 

We  have  not  identified  a  source  for  validated  RF  HELLFIRE  trajectory  data  but 
AMSAA  can  provide  weapon  test  flight  data  in  plot  format . 


ADST/TR  94-003282 


April  15,  1994 


Table  7.3.3.2.3  shows  the  structure  and  output  validation  activities  that  ate  to  be 
performed  during  each  development  phase  for  this  component 
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Table  7.3.3.2.3  Structure  and  Output  Validation  Activities  for  AH-64D  We^ons 


7. 3.3. 2.4  AH-64D  Sensors 

The  sensor  validation  process  should  include  collection  of  CIG  display 
characteristics  and  calibration  methodologies  to  provide  CIG  metrics  for  the  simulated 
acquisition  sensors.  A  series  of  tests  would  then  be  conducted  on  the  simulator  to 
determine  the  functions  which  describe  the  deviations  between  observer  simulated  target 
response  and  the  real  world,  and  to  determine  how  great  a  departure  from  reality  can  be 
tolerated.  Additional  testing  with  trained  crewmen  to  determine  if  the  simulator  and  models 
produce  rcalistic  detection  and  acquisition  results  as  a  full  dcmo/facc  validation. 
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Table  7.3.3.2.4  shows  the  structure  and  output  validation  activities  that  are  to  be 
performed  during  each  develofmient  phase  for  this  component 


Phase: 

Activity: 
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1  Documentation  and  Reviews 
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1  Test  and  Evaluadon 

V 

Table  7.3.3.2.4  Structure  and  Output  Validation  Activities  for  AH'64D  Sensors 


7.3.3.2.5  AH-64DASE 

Radar-Warning  apr-39  (V)1  (V)2 
APR-48 

The  task  is  to  validate  that  if  the  Tactical  and  Natural  Environment  (TNE)  Segment 
emission  environment  contains  RF  signals  which  are  then  represented  by  protocol  data 
units  (PDUs),  then  the  APR-39  and  APR-48  would  detect,  identify,  and  generate  the 
correct  alerts. 

Validate  the  system  at  the  segment  level  by  testing  that  the  following  parameters  are 
properly  computed  in  accordance  with  the  radar  warning  adaptability  parameters;  EID  file; 
threat  emitter  type,  location,  power,  mode,  and  beam  characteristics;  and  ownship  location 
and  orientation: 

-  equipment  functional  status  from  electric  power  indications  and  sustained  battle 

damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  siir.iained  battle 

damage  in  the  areas  of  the  equipment  and/or  sensors 

-  ittentification  in  accordance  with  ETD  file  and  emitter  beam  pai  amcters 

-  maximum  detection  range  and  range  estimate  from  ID,  EID  file  and  detected 

power 

-  detecUon/no  detection  from  maximum  range  and  threat  and  ownship  locations 

-  coarse  radar  site  list  for  radar  warning  receiver  and  radar  jammer  operation 

-  emitter  mode  (search,  acquisition,  track,  or  missile  activity)  from  EID  file  and 

emitter  beam  characteristics  and  activity 

-  emitter  relative  bearing  from  AOA  information  and  ownship  heading 

-  emitter  priority  based  on  priority  in  EID  file,  detecting  equipment  and  range 
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-  emitter  location  based  on  range  and  bearing 

-  emitter  location  based  on  triangulation  imxxssing  by  multiple  team  members 
•  radar  warning  indications  (up  to  8  visuk  effects  and  up  to  S  visual  effects), 

prioritized  target  list  and  other  interface  parameters  computed  and  passed 

-  detection  charactetistics  can  be  modified  within  the  limits  of  the  radar  warning 

adaptability  parameters 

Validate  the  system  at  the  device  and  simulator  system  level  by  confirming  that  it  will 
detect  threats  that  are  on  the  network  and  cause  the  appropriate  warnings  to  be  activated. 
NEEDED:  APR-39  (V)l  (V)2,  APR-48  performance  description. 

Radar  Jammer  ALX>136  (V)l/S 

The  task  is  to  validate  that  the  radar  jammer  outputs  defined  in  the  PDU  accurately 
depict  the  signals  that  would  jam  the  radars  detected  by  the  RWR. 

Validate  the  system  at  the  segment  level  by  testing  that  the  following  parameters  are 
properly  computed  in  accordance  with  the  radar  jammer  adaptability  parameters;  EID  file  ; 
course  radar  site  list;  and  ownship  location  and  orientation: 

-  equipment  functional  status  from  electric  power  indications,  ECM  enable  status 

and  sustained  battle  damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  the  areas  of  the  equipment  and/or  antennas 

-  emitter  detected  if  on  course  radar  site  list  generated  by  radar  warning  receiver 

-  emitter  prioritized  in  accordance  with  EID  file  and  range  between  emitter  site 

location  and  ownship  location 

-  AO  A  evaluations  using  ownship  angular  position  values,  actual  earth  axis  azimuth 

and  elevation  to  the  emitter,  and  EID  file  error  indications 

-  radar  jamming  parameters  using  results  of  the  AOA  evaluations,  the  RF  emitter's 

beam  parameters  and  the  EID  file  jamming  indications 

-  RF  jamming  characteristics  required  to  effectively  simulate  the  jamming  of  the 

selected  emitters  (up  to  10)  and  other  interface  parameters  computed  and 
passed 

-  jamming  characteristics  can  be  modified  within  the  limits  of  the  radar  jammer 

adaptability  parameters 

Validate  the  system  at  the  device  and  simulator  system  level  by  confirming  that  it 
will  realistically  jam  RF  threats  that  tue  on  the  network. 

NEEDED:  AL(J-136  (V)l/5  performance  description. 

Laser  Warning  AVR-2(V)  TBD 

The  task  is  to  validate  that  it  the  Tactical  and  Natural  Environment  (TNE)  Segment 
emission  environment  contains  laser  signals,  then  the  AVR-2  would  detect,  identify,  and 
generate  the  correct  alerts. 

Validate  the  system  at  the  segment  level  by  testing  that  the  following  parameters  are 
properly  computed  in  accordance  with  the  laser  warning  adaptability  parameters;  laser  ID 
file;  laser  type,  location,  power,  code,  and  beam  characteristics;  and  ownship  location  and 
orientation: 

-  equipment  functional  status  from  electric  power  indications  and  sustained  battle 

damage 
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-  reduced  capabitity  or  total  failure  of  the  function  as  a  result  of  sustained  bittUe 

damage  in  the  areas  of  the  equipment  and/or  sensors 

-  identificaticHi  in  accordance  with  laser  ID  file  and  laser  beam  parameters 

-  maximum  detection  range  and  range  estimate  fimn  ID,  laser  ^  file  and  detected 

power 

-  detection/no  detection  from  maximum  range  and  laser  and  ownship  locations 

-  laser  code  from  laser  ID  file  and  laser  beam  characteristics 

-  laser  relative  bearing  from  AOA  information  and  ownship  heading 

-  laser  priority  based  on  primity  in  laser  ID  file  and  range 

-  emitter  location  based  on  range  and  bearing 

-  emitter  location  based  on  triangulatkxi  processing  by  multiple  team  members 

-  laser  warning  indications  (up  to  TBD  visual  effects  and  up  to  TBD  visual  effects), 

prioritized  target  list  and  other  interface  parameters  computed  and  passed 
'  detection  characteristics  can  be  modified  within  the  limits  of  the  IR  warning 
adaptability  parameters 

Validate  the  system  at  the  device  and  simulator  system  level  by  confirming  that  it 
will  detect  threats  that  are  on  the  network  and  cause  the  appropriate  warnings  to  be 
activated. 

NEEDED:  AVR-2  (V)  performance  descr^on. 

IR  Jammer  AL(J-144  (V)l/3 

The  task  is  to  validate  that  the  IR  jammer  outputs  defined  in  the  PDU  accurately 
depict  the  signals  that  would  jam  IR  sensors. 

Validate  the  system  at  the  segment  level  by  testing  that  the  following  parameters  are 
properly  computed  in  accordance  with  the  IR  jammer  adaptability  parameters;  IR  jammer 
characteristics;  location  of  IR  seeker,  and  owns^p  location: 

-  equipn>cnt  functional  status  from  electric  power  indications,  ECM  enable  status 

and  sustained  battle  damage 

-  reduced  capability  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  die  areas  of  the  equipment  and/or  IR  element 

-  IR  jamming  parameters  for  simulation  of  the  cooldown  and  warmup  cycling 

tecluiique 

-  IR  jamming  characteristics  and  other  interface  parameters  computed  and  passed 
-jamming  characteristics  can  be  modified  within  the  limits  of  the  IR  januner 

adaptability  parameters 

Validate  the  system  at  the  device  and  simulator  system  level  by  confirming  that  it 
will  realistically  jam  IR  threats  dial  are  on  the  network. 

NEEDED:  AI^144  (V)l/3  performance  description. 

Chaff  M-I  M-130  Dispenser 

The  task  is  to  validate  that  the  chaff  cloud  characteristics  defined  in  the  PDU 
accurately  depict  chaff  velocity,  dispersion  pattern,  and  radar  cross  section. 

Validate  the  system  at  the  segment  level  by  testing  that  the  following  parameters  are 
properly  computed  in  accordance  with  the  cha^f  adaptability  parameters;  pilot  switch 
selection  and  actions;  and  ownship  location: 
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-  equipment  functional  status  from  electric  power  indications,  chaff  invoibny,  chaff 

selection  and  sustained  battle  damage 

-  reduced  ciqMbility  or  total  failure  of  the  function  as  a  result  of  sustained  battle 

damage  in  the  areas  of  tire  equipment  and/or  dispenser 

-  chaff  dispensed  upon  command  when  manual  mode  selected 

-  chaff  disjrensed  in  accordance  with  system  characteristics  or  adi^ttal^ty 

parameters  when  automatic  mode  selected 

-  chaff  inventory  decremented  by  the  number  of  bundles  dispensed 

•  retease  indication  and  other  interface  parameters  computed  and  passed 

-  delivery  system  characteristics  and/or  chaff  characteristics  can  be  modified  within 

the  limits  of  the  chaff  adaptal^ity  parameters 
Validate  the  system  at  the  device  and  simulator  system  level  by  confirming  that  the 
chaff  realistically  affects  the  perfrmnance  of  threat  RF  missiles  that  are  on  the  network. 

We  have  not  identified  a  validated  source  of  chaff  characteristics. 

NEEDED;  Chaff  M-I  performance  description. 

Table  7.3.3.2.S  shows  the  structure  and  output  validation  activities  that  are  to  be 
performed  during  each  development  phase  for  this  comptmenL 
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Table  7.3.3.2.5  Structure  and  CXitput  Validation  Activities  for  AH-64D  ASE 


7.3.3.2.6  AM-64D  Flight  Dynamics 

The  ARWA  AH-64D  flight  dynamics  will  be  quantitatively  validated  against 
reference  (flight  test)  data  to  assure  the  validity  of  the  simulation,  llie  following  tables 
enumerate  tests  to  be  conducted  in  flight  test  and  duplicated  in  the  ARWA  AH-64D 
simulator.  During  etreh  of  these  tests  the  af^ropriate  control  positions,  pilot  ^plied  forces, 
propulsion  parameters  and  aircraft  state  variables  will  be  recorded.  Time  l^tories  and 
cross  plots  of  these  parameters  will  be  compared  with  reference  data  to  validate  the 
simulation  hardware  and  software  models.  These  tests  will  be  performed  over  a 
representative  range  of  flight  conditions  covering  the  aircraft  operating  envelope  and  with 
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each  apidicabk  airciaft  coofigiBitk»  to  coofirai  the  e£GKtt  on  the  ancnlt  fligitt  dyiuu^ 
The  tests  will  be  repeated  widi  stability  augmentation  on  and  off  to  demonstrate  the 
appn^xiate  effects. 

QuantitatiTe  Performance  Validation  Tests 

1)  One  Engine  Inoperative  Takeoff  Performance 

2)  Hover  Performance  (ICE.  OGE) 

3)  Normal  Climb  Performance 

4)  Engine  Out  Climb  Petformaiice 

5)  Cruise  Performance 

6)  Normal  Descent  Performance 


Quantitative  Handling  Qualities  Validation  Tests 

1)  Low  Speed  Translational  Flight  (Forward.  Aft,  Left,  Right) 

2)  Critical  Azimuth  Stationary  Hover 

3)  Control  Re^nse  in  Hover  (Long.,  Lateral,  Directional,  Vertical) 

4)  Longitudinal  Control  Response  to  Step  Inputs 

5)  Longitudinal  Static  Stability 

6)  Longitudinal  Dynamic  Stability,  Long  Term 

7)  Longitudinal  Dynamic  Stability,  Short  Term 

8)  IxMigitudinal  Maneuvering  Stability 

9)  Lateral  Response  to  Step  Inputs 

10)  Directionsd  Response  to  Step  Inputs 

1 1)  Directional  Static  St2d)ility 

12)  Lateral/Direction  Dynamic  Stability 

.  13)  Spiral  Stability 

14)  Adverse/Proverse  Yaw 

15)  Vertical  Re^nse  to  Primary  Collective  Step  Inputs 

The  quantitative  evaluation  of  the  flight  dynamics  will  be  supplemented  with  a 
subjective  evaluation  of  the  ARWA  AH-64D  simulator  handling  qualities.  In  this  phase  of 
the  evaluation  it  is  a  fundamental  requirement  to  utilize  pilots  who  are  intimately  familiar 
with  the  AH-64D  flight  dynamics  and  performance.  Access  to  a  AH-64D  helicopter  will  be 
provided  to  tire  evaluation  pilots  prior  to  and  during  this  assessment  The  use  of  at  least  3 
quaUfied  pilots  will  insure  a  thorough  and  accurate  evaluation  of  the  simulator.  The 
following  table  lists  the  flight  operations  to  be  performed  during  the  subjective  evaluation. 
T<^sts  in  iririch  flight  director  guidance  is  tqrplicable  will  be  duplicated  using  the  flight 
director  engaged  and  utilized  as  the  primary  reference. 

During  the  handling  qualities  assessment  each  of  the  following  criteria  will  be 
addressed:  a)  aircraft  stability,  b)  aircraft  controllability,  c)  pilot  woricload,  d)  precision  of 
task,  e)  rq^iiropriateness  of  control  inputs  and  f)  cmrelation  of  visual,  aural  and  motion  cues 
to  flight  condition.  The  pilots  will  check  that  the  ARWA  RAH-66  simulator  reproduces 
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fidelity  of  flight  operatioiis  to  a  level  which  will  closely  resemble  that  of  the  engineering 
simulator  and  which  will  not  cause  either  di^raction  of  the  pilot  or  an  increase  w  decrease 
in  the  performance  of  the  air  vehicle  to  an  extent  that  would  affect  combat  effectiveness  or 
associated  test  results. 

Handling  Qualities  Assessment  Tests 

1)  Hovering  Turns  With  Wind 

2)  Rejected  Takeoff 

3}  Aborted  Landing 

4)  Nap  of  the  Earth  Flight  Over  Terrain 

5)  Ground  Target  Tracking 

6}  Ground  Attack  We^xxi  Delivery 
^  7)  Ground  To  Air  Weapon  Avoidance 

8)  Air  Target  Tracking 

9}  Air  to  Air  Combat  Maneuvering 

10)  Air  to  Air  Wetqmn  Hting 

1 1)  Air  to  Air  Weapon  Avoidance 

12)  Flight  with  Selected  Combinations  of  Ordinance  Installed 

13)  Flight  With  Selected  Propulsion  System  Battle  Damage 

14)  Flight  With  Selected  Fli^t  Control  Battle  Damage 

15)  Flight  With  Selected  APCS  Battle  Damage 

16)  Flight  With  Selected  Aiiffame  Battle  Dam^e 

The  effects  of  battle  damage  to  the  flight  controls  will  be  validated  by  subjective 
pilot  evaluation  substantiated  with  engineering  analysis  of  the  resultant  effects. 

Table  7.3.3.2.6  shows  the  structure  and  output  validation  activities  tliat  are  to  be 
performed  during  each  development  phase  for  this  component 


We-PPk 

pDR-Cdr 

Structure  Validation 

Documentation  and  Reviews 

V 

V 

V 

■HTrTRilS'/irinrWdillillUlUililflH 

V 

,  SW  Architecture  Assessment 

V 

V 

V 

V 

V 

V 

V 

V 

V 

Mk  #:T  tfi  1 (TriTiTimHmH 

V 

Table  7.3.3.2.6  Structure  and  Ou^ut  Validation  Activities  for  AH-64D  Flight 

Dynamics 


- 137- 


ADST/TR  944)03282 


April  IS,  1994 


7.3.3.2.7  AH-64D  Propulsion 

The  ARWA  AH-64D  engine  and  propulsion  system  will  be  quantitatively  validated 
against  reference  (engine  deck  and  flight  test)  data  to  assure  the  validity  of  the  simulation. 
The  following  list  enumerates  tests  to  be  ctxiducted  and  duplicated  in  the  ARWA  AH-64D 
simulator.  During  each  of  these  tests  the  appropriate  engine  and  propulsion  system 
parameters  (Gas  generator  speed.  Power  turbine  ^ed.  Fuel  flow.  Engine  torque,  Turbine 
gas  temperature.  Engine  oil  pressure  and  temperature.  Main  rotor  speed  and  Tail  rotor 
speed)  will  be  recorded.  Time  histories  and  cross  plots  of  these  parameters  will  be 
compared  with  reference  data  to  validate  the  simulation  software  models.  These  tests  will 
be  performed  at  applicable  temperatures,  airspeeds  and  altitudes  to  include  the  operating 
envelope  of  the  AH-64D. 

Quantitative  Engine  and  Propulsion  System  Validation  Tests 

1)  R<q)id  Engine  Accelerations 

2)  Rapid  Engine  Decelerations 

3)  Nominal  Rate  Engine  Accelerations 

4)  Nominal  Rate  Engine  Decelerations 

5)  Steady  State  Engine  Operation 

6)  Power  Turbine  Trim  Speed  Change  Response 

7)  Engine  and  Rotor  Speed  Governing  Demonstration 

The  validation  of  the  engine  and  propulsion  system  may  be  supplemented  by  the 
tests  to  be  performed  in  the  flight  dynamics  validation  (see  Section  7.3.3.2,6)  depending 
upon  the  model  design  and  complexity.  Due  to  Uie  intimate  coupling  between  the 
propulsion  system  and  the  flight  dynamics  many  of  the  tests  described  in  the  flight 
dynamics  validation  may  also  serve  to  validate  these  modules  simultaneously.  The  effects 
of  battle  damage  to  the  propulsion  system  may  also  be  validated  by  subjective  evaluation 
substantiated  with  engineering  analysis  of  the  resultant  effects. 

The  effects  of  battle  damage  to  the  propulsion  system  will  be  validated  by  subjective 
evaluation  substantiated  with  engineering  analysis  of  the  resultant  effects. 
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Table  7.3.3.2.7  shows  the  structure  and  ouQ)ut  validation  activities  that  are  to  be 
performed  during  each  development  phase  of  this  component 


Table  7.3.3.2.7  Structure  and  Ou^ut  Validation  Activities  for  AH-64D  Propulsion 


7.3.3.2.8  AH-64D  Physical  Cues 

Validation  will  consist  of  the  insuring  proper  sensory  cues  are  provided  for  the 
varied  environmental  effects  available  in  each  test 


Table  7.3.3.2.8  shows  the  structure  and  output  validation  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 


Table  7.3.3.2.8  Structure  and  Ou^rut  Validation  Activities  for  AH-64D  Physical 

Cues 
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7.3.3.2.9  AH-64DTNE 

The  Tactical  and  Natural  Environment  segment  will  receive  special  attention  for, 
through  it,  the  ARWA  SS  interfaces  with  the  rest  of  the  Multiple  Simulator  Environment 
(MSE).  And  since  these  data  then  flow  to  and  from  the  other  segments  of  the  AH-64D 
Simulator  System  Module,  in  order  to  interact  with/stimulate  their  models,  the  proper 
implementation  and  functioning  of  the  TNE  segment  is  crucial  to  the  proper  functioning  of 
the  entire  AH-64D  Simulator  System  Module.  Validation  at  the  segment  level  will  require 
tests  of  the  following  areas  to  verify  that  the  functions  operate  properly: 

Network  Interface  Function 

-  Provide  for  information  updates  conforming  to  the  Distributed  Interactive 

Simulation  (DIS)  standard. 

-  Provide  this  information  to  the  ongoing  simulation  of  the  ovvnship  environment  as 

appropriate. 

-  Perform  all  necessary  conversions  to  conform  to  ARWA  internal  data  formats  and 

units. 

Atmosphere  Function 

-  Provide  for  simulation  of  a  medium  fidelity  atmosphere. 

-  Simulate  air  mass,  global  winds,  and  turbulence. 

-  Provide  global  definitions  of  temperature  and  pressure. 

External  Entities  Function 

-  Simulate  the  position  and  attitude  of  other  vehicles  between  updates  from  the 

multi-simulator  environment  (MSE). 

-  Upon  receiving  such  updates,  the  TNE  segment  shall  seamlessly  inject  the  new 

data  into  the  vehicle  simulation. 

Qwnship  Weapon  Damage  Function 

-  Provide  to  the  MSE  information  regarding  ownship  weapon  path,  detonation  and 

ordinance. 

-  The  information  shall  be  passed  through  to  the  external  simulation  through  the 

Nctworic  Interface  function. 

Threat  Weapon  Dynamics  Function 

-  Simulate  the  flight  of  threat  weapons  between  updates  from  the  MSE. 

Threat  Platform  Dynamics  Function 

-  Simulate  the  flight  of  threat  platforms  between  updates  from  the  MSE. 

Validation  of  the  TNE  .segment  at  lire  device  and  simulator  sysieni/MSE  level  will 
require  tests  of  the  following  areas  to  verify  that  the  functions  operate  properly: 

-  Create  a  scenario  with  one,  then  multiple,  ownships,  terrain,  threats,  targets  and 

other  tactical  elements.  Cause  elements  of  the  tactical  threat  environment  to 
take  actions  that  will  provide  stimuli  for  all  AH-64D  weapon  systems. 

-  Employ  all  ownship  sensors  to  detect  threats  and  targets.  Confirm  that  the 

sensors  operate  realistically. 

-  Employ  all  ASE  systems  to  detect  threats  and  to  defeat  them  through  RF  and  IR 

jamming  and  the  employment  of  chaff  and  flares.  Confirm  that  the  ASE 
systems  operate  realistically. 
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-  Target  both  air  and  ground  targets  and  employ  all  air-to-air  and  air-to-ground 

weapons  against  them.  Confirm  that  all  AH-64D  weapon  systems  can  kill 
or  d^age  and  that  they  operate  realistically. 

-  Employ  all  nav/com  systems  and  confirm  that  they  operate  realistically. 

-  Confirm  that  the  visuals  ate  present  and  are  updated  smoothly. 

-  Confirm  that  all  ^)ecial  effects  and  physical  cues  ate  presented  in  a  realistic 

manner. 

-  Confirm  that  all  controls  and  displays  operate  in  a  realistic  manner. 

-  When  ownship  receives  fire,  coirfirm  that  damage  received  is  realistic. 

Table  7.3.3.2.9  shows  the  structure  and  output  validation  activities  that  are  to  be 
performed  during  each  development  phase  for  this  component 
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8.0  ACCREDITATION 

This  section  defines  the  specific  activities  required  for  accreditation  for 
each  of  the  components  of  the  ARWA  SS. 

8.1  VSM 
TBD 

8.2  FSM 
TBD 

8.3  SSM 
TBD 

8.3.1  RAH-66  Comanche  Kit 


TBD 

8.3. 1.1 

RAH-66  Flight  Controls 

TBD 

8. 3.1.2 

RAH-66  Nav/Comm 

TBD 

8.3. 1.3 

RAH-66  Weapons 

TBD 

8.3. 1.4 

RAH-66  Sensors 

TBD 

8.3. 1.5 

RAH-66  ASE 

TBD 

8.3. 1.6 

RAH-66  Flight  Dynamics 

TBD 

8.3. 1.7 

RAH-66  Propulsion 

TBD 

8.3. 1.8 

RAH-66  Physical  Cues 

TBD 
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8.3. 1.9  RAH-66  TNE 

TBD 

8.3.2  AH-64D  Longbow  Kit 
TBD 

8.3. 2.1  AH-64D  Flight  Controls 
TBD 

8. 3. 2. 2  AH-64D  Nav/Comm 

TBD 

8. 3. 2. 3  AH-64D  Weapons 

TBD 

8. 3. 2. 4  AH-64D  Sensors 

TBD 

8. 3.2. 5  AH-64D  ASE 

TBD 

8. 3. 2.6  AH-64D  Flight  Dynamics 

TBD 

8. 3. 2. 7  AH-64D  Propulsion 

TBD 

8. 3. 2. 8  AH-64D  Physical  Cues 

TBD 

8. 3. 2.9  AH-64D  TNE 

TBD 

9 .  LIST  OF  ACRONYMS 
A/C  Aircraft 

ADST  Advance  Distributed  Simulation  Technology 

AFCS  Automatic  Right  Control  Systems 

ALWSIM  Army  Laser  Weapon  Simulation 

AMSAA  Army  Material  Systems  Analysis  Activity 


- 143- 


1 

1 

] 

ADST/TR  94-003282 

April  15,  1994 

1 

ARWASS 

Advanced  Rotary  Wing  Aircraft  Simulator  System 

ASE 

Aircraft  Survivability  ^uipment] 

■ 

ATAS 

Air  to  Air  System 

■ 

ATOS/EATHS 

Auuxnatic  Target  Handover  System  /  Enhanced 

ATHS 

1 

BDS-D 

Battlefield  Distributed  Simulation  Development 

BRL 

Ballistic  Research  Laboratory 

1 

CADC 

Central  Air  Data  Computer 

CASE 

Computer  Aided  Software  Engineering 

■ 

CASTFOREM 

Constructive  Fruce  on  Force  Combat  Simulation 

1 

CCB 

Configuration  Control  Board 

QG 

Computer  Image  Generation  (Generator) 

■ 

CLOS 

Continuous  Line  Of  Sight 

1 

CM 

Configuration  Management 

COTS 

C(xnmcrcial  Off  The  Shelf 

■ 

CSC 

Computer  Software  Components 

1 

CSCI 

Computer  Software  Configuration  Items 

CSU 

Con^uter  Software  Units 

1 

CUT 

Code  and  Unit  Test 

■ 

DIS 

Distributed  Interactive  Simulation 

DNS 

Doppler  Navigation  System 

1 

DO 

DeUvery  OrdCT 

1 

EDASE 

Enhanced  Digital  Automatic  Stabilization 

Equipment 

FEAR 

Folding  Fin  Aerial  Rocket 

1 

FLIR 

Forward  Looking  Infra-Red 

■ 

FSM 

Flight  Station  Module 

1 

GFE 

Government  Furnished  Equipment 

■ 

GPS 

Global  Positioning  System 

GROUNDWARS/GWARS 

Force-on-Force  combat  simulation  using  Night 

1 

Vision  Laboratory  m<Klels 

HARS/AHRS 

Heading  and  Attitude  Reference  System 

1 

IDD 

Interface  Design  Defmition 

IDM 

Improved  Data  Modem 

1 

IRS 

Interface  Requirements  Specification 

LAN 

Local  Area  Network 

■ 

LORAM 

Low  Observable  Radar  Model 

1 

LWR 

Laser  Warning  Receiver 

1 

METL 

Mission  Essential  Task  List 

1 
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ModSAF 

MRC 

MRTD 

MSE 

ms/fms 

PDU 

RCS 

RF 

RWR 

SAFOR 

SAL 

SDD 

SDF 

SFA 

SOW 

SRS 

SSM 

SSS 

STD 

ST? 

STR 

TADS/EOTADS 

TBD 

TES 

TNE 

TRR 

TSA 

VSM 

v&v 

WAN 

SVDL 


Modular  Semi- Automated  Forces 
Minimum  Resolvable  Contrast 
Minimum  Resolvable  Temperature  Difference 
Multiple  Simulator  Environment 

Night  Vision  System  /  Pilot  Night  Vision  System 

Protocol  Data  Units 

Revision  Control  System 
Radio  Frequency 
Radar  Warning  Receiver 

Semi- Automated  Forces 
Semi- Active  Laser 
Software  Design  Document 
Software  Development  File  (Folder) 

Selected  Fidelity  Analysis 
Statement  of  Work 
Software  Requirements  Specification 
Simulator  System  Module 
System  /  Segment  Specification 
Software  Test  Description 
Software  Test  Plan 
Software  Test  Report 

Target  Acquisition  Detection  System 
To  Be  Determined 
Tactical  Environment  Simulation 
Tactical  and  Natural  Environment 
Test  Readiness  Review 
Task  Skills  Analysis 

Visual  System  Module 
Verification  and  Validation 

Wide  Area  Network 
Western  Development  Labs 
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APPENDICES 

An  appendix  entry  will  be  added  in  the  future  whenever  the  ARWA  Simulator  must 
undergo  veriflcation  and  /  or  validation  of  any  enhancements.  One  appendix  for  each 
addition  will  describe  the  enhancement  and  /  or  software  /  hardware  modification  and  why 
the  new  V&V  needs  to  be  performed. 
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